DirtyDecrypt PoC Released: Linux Kernel rxgk LPE Now Weaponised Post-Patch
A proof-of-concept exploit has been released for DirtyDecrypt, a recently patched local privilege escalation vulnerability in the Linux kernel's rxgk module. Attackers with local access can now more easily achieve root-level code execution on affected systems.
Affected
The availability of a functional exploit for DirtyDecrypt marks the transition from theoretical to practical threat. While the underlying vulnerability has been patched upstream, the real-world impact depends entirely on whether affected systems have deployed the fix, a slow process across heterogeneous Linux environments. This is not a remote code execution vector; attackers require local system access first, which constrains the threat to multi-tenant servers, shared hosting environments, and systems where untrusted users have shell accounts.
The rxgk module itself is relatively obscure within the broader Linux ecosystem, suggesting this vulnerability affects a specific subset of deployments rather than the majority of Linux systems. However, organisations running legacy systems or those with extended support requirements may remain vulnerable for extended periods. The patch-to-exploit timeline here is notably aggressive: vulnerability disclosure followed quickly by PoC release. This pattern reflects the maturing state of kernel vulnerability research and the value placed on demonstrating proof-of-concept code.
Defenders should prioritise identifying systems with the rxgk module loaded. Many distributions and custom kernel builds do not include this module by default, making this a scoped rather than universal risk. Systems that do carry rxgk should be assessed for patch status and prioritised for updates according to risk profiles. On multi-user systems, this vulnerability should inform access control decisions, particularly around which users can be granted local shell access.
The broader implication is that kernel-level LPE vulnerabilities remain a reliable attack vector in environments where local access can be obtained through other means: application compromise, container escape, or compromised user credentials. Organisations should treat kernel updates as security-critical rather than routine maintenance, especially for modules supporting less common protocols or use cases. The existence of public exploits does not retroactively make older patches irrelevant, but it does reduce the window during which unpatched systems remain inconspicuous targets.
Sources