Technical Analysis: The DirtyDecrypt (DirtyCBC) Linux Kernel LPE Exploit

The theoretical landscape of Linux kernel exploitation has shifted significantly with the public release of Proof-of-Concept (PoC) code for DirtyDecrypt (also known as DirtyCBC). What was once a localized vulnerability has transitioned into a practical, highly reliable local privilege escalation (LPE) path, allowing unprivileged users to achieve root access on specific Linux distributions.

DirtyDecrypt targets the RxGK security layer within the Linux kernel’s RxRPC transport protocol, which is utilized by the Andrew File System (AFS). While the vulnerability is technically associated with CVE-2026-31635, there is a notable discrepancy in documentation: the NVD entry describes a Denial-of-Service (DoS) bug, whereas the actual exploitable primitive enables full privilege escalation.

The Mechanics of the Vulnerability

The core flaw resides within the rxgk_decrypt_skb() function. During the decryption of incoming RxGK RESPONSE tokens, the kernel processes sk_buff data that may alias with page-cache pages—specifically when supplied via MSG_SPLICE_PAGES.

The exploitation succeeds due to two critical architectural oversights:

1. Decryption-before-Verification: The kernel performs decryption operations before validating the Message Authentication Code (MAC).
2. Lack of Copy-on-Write (CoW) Protections: The code fails to implement a proper guard to ensure that decrypted data is not written into shared memory.

By exploiting this, an attacker can force the kernel to write decrypted bytes directly into page-cache pages belonging to other processes or sensitive system files, such as /etc/shadow or SUID binaries.

Exploit Walkthrough: From Unprivileged User to Root

The security research team at Zellic and V12, led by Luna Tong (cts/gf_256), developed a PoC that weaponizes this page-cache write primitive. The attack vector follows a precise execution chain:

rxgk_verify_response() → rxgk_extract_token() → rxgk_decrypt_skb() → skb_to_sgvec() → crypto_krb5_decrypt().

By driving this path, the attacker forces the kernel to decrypt attacker-controlled ciphertext into aliased page-cache pages. Technical analysis from Delphos Labs indicates that the attack utilizes an AES-CBC chosen-plaintext construction. In a real-world scenario, the PoC “poisons” the page cache of a readable SUID-root binary. Once the cache is poisoned, executing that binary grants the attacker immediate root privileges without the need for brute-force attacks or complex CoW race conditions.

Figure 1: Visualizing the impact on Linux distributions (Source: Infosec Exchange)

Affected Ecosystems and Attack Surface

The exploitability of DirtyDecrypt is highly dependent on the kernel configuration. It specifically requires CONFIG_RXGK to be enabled. Consequently, the risk is concentrated in rolling-release distributions and development-focused environments:

• Fedora (including Rawhide): High risk if running unpatched kernels with RxGK enabled.
• Arch Linux: High risk due to the close adherence to mainline kernel configurations.
• openSUSE Tumbleweed: Vulnerable where RxGK is compiled into the kernel.

In enterprise environments, the risk is mitigated by the fact that many stable distributions disable RxGK by default. However, in Kubernetes environments, the threat is acute. If a worker node runs a vulnerable rolling-release kernel, an attacker can use DirtyDecrypt to escape a container pod and gain full control over the host node and all other pods residing on it.

Patching and Structural Remediation

While early patches (such as commits a2567217, beee051f, and e2f1a80d) addressed the DoS aspect of the vulnerability, they did not resolve the underlying LPE primitive.

According to Moselwal’s technical breakdown, the definitive fix was introduced in commit aa54b1d27fe0 (merged May 10, 2026). This commit implements a structural change that copies RxRPC DATA/RESPONSE packets whenever shared fragments are detected, ensuring that in-place decryption never touches aliased page-cache pages.

Figure 2: Impact analysis on Fedora systems (Source: Infosec Exchange)

Mitigation and Defensive Strategy

Security operations teams should adopt a multi-layered approach to defense:

1. Immediate Remediation

Prioritize kernel updates that specifically include the May 10, 2026 structural fix (aa54b1d27fe0). If patching is not immediately possible, consider the “module-level” workaround: unload and blacklist esp4, esp6, and rxrpc. Note: This will disable IPsec VPNs and AFS mounts.

2. Detection and Monitoring

Since the exploit utilizes legitimate kernel code paths, traditional log-based detection is often insufficient. Recommended methods include:

• Fleet Auditing: Run automated sweeps to identify systems with CONFIG_RXGK enabled and vulnerable kernel versions.
• Behavioral Monitoring: Utilize eBPF-based tools (like Falco) to monitor for unusual modprobe rxrpc invocations.
• Privilege Monitoring: Watch for unexpected UID transitions originating from non-systemd processes, which may indicate a successful LPE.