PoC Exploit Released for DirtyDecrypt Linux Kernel Vulnerability

PoC exploit code for the DirtyDecrypt (DirtyCBC) Linux kernel vulnerability has been released publicly, turning a previously theoretical local privilege escalation into a practical, copy‑paste exploit path to root on specific Linux distributions.

DirtyDecrypt (also called DirtyCBC) is a local privilege escalation (LPE) in the Linux kernel’s RxGK security layer for the RxRPC transport used by the Andrew File System (AFS).

The issue is currently associated with CVE‑2026‑31635 because the NVD entry links directly to the public PoC, even though the original CVE text describes a related denial‑of‑service bug in the same code path.

The bug lives in rxgk_decrypt_skb(), where the kernel decrypts incoming RxGK RESPONSE tokens over sk_buff data that may alias page‑cache pages supplied via MSG_SPLICE_PAGES.

Because the code decrypts before verifying the MAC and lacks a proper copy‑on‑write guard, those decrypted bytes can be written directly into page‑cache pages belonging to other processes or to privileged files such as /etc/shadow or SUID binaries.

PoC Exploit for DirtyDecrypt

The Zellic and V12 security team, led by Luna Tong (cts/gf_256), has released a working PoC that exploits this page‑cache write primitive to achieve full root on affected systems. The exploit drives the RESPONSE‑packet path rxgk_verify_response() → rxgk_extract_token() → rxgk_decrypt_skb() → skb_to_sgvec() → crypto_krb5_decrypt(), forcing the kernel to decrypt attacker‑controlled ciphertext into aliased page‑cache pages.

Delphos Labs’ primary analysis shows that the attack combines decrypt‑before‑MAC semantics with an AES‑CBC chosen‑plaintext construction using an attacker‑controlled key on the server side.

In practice, the PoC poisons the page cache of a readable SUID‑root binary and then executes it, giving the attacker root without a brute‑force component or a race on copy‑on‑write.

Affected systems and configurations

DirtyDecrypt only works on kernels built with CONFIG_RXGK enabled, which sharply narrows the affected distribution set. Current reporting and public testing indicate the real‑world impact is concentrated on:

• Fedora (including Rawhide) with RxGK enabled and unpatched kernels.
• Arch Linux and derivatives follow the mainline closely.
• openSUSE Tumbleweed and other rolling‑release platforms with RxGK compiled in.

The PoC has been validated primarily against Fedora and mainline kernels. In contrast, many traditional enterprise distributions disable RxGK in their shipping configurations.

In containerized environments, the risk lies on Kubernetes worker nodes running these rolling‑release kernels, where a successful LPE in the host kernel becomes a pod-escape path.

NVD’s CVE‑2026‑31635 description focuses on an inverted length check in rxgk_verify_response() that can trigger a kernel BUG and denial of service when oversized authenticators reach skb_to_sgvec().

Stable kernels began shipping fixes for that condition in April 2026 via commits such as a2567217…, beee051f… , and e2f1a80d….

According to Moselwal, DirtyDecrypt’s LPE primitive is addressed more structurally by commit aa54b1d27fe0, merged on 10 May 2026, which copies RXRPC DATA/RESPONSE packets when shared fragments are present so that in‑place decrypt never touches aliased page‑cache pages.

This change originated in the Dirty Frag / Copy Fail hardening work (CVE‑2026‑43284 and CVE‑2026‑43500) and protects the DirtyDecrypt path even though it is not explicitly referenced in the NVD record for CVE‑2026‑31635.

Researchers have placed DirtyDecrypt in the same “dirty” family as Copy Fail, Dirty Frag, and Fragnesia, all of which exploit subtle mistakes around page‑cache handling and in‑place cryptographic operations to gain a privileged write primitive.

From an attacker’s perspective, DirtyDecrypt is a second‑stage exploit: it turns an existing foothold into root. However, it does not provide initial remote code execution on its own.

Typical entry vectors include compromised SSH credentials, vulnerable web applications, or a compromised container image that grants an attacker access to a pod as an unprivileged user.

On a Kubernetes worker node running a vulnerable kernel with RxGK enabled, successful exploitation grants the attacker full control of the host, including access to all pods, container runtime sockets, and any Kubernetes secrets mounted on that node.

On developer or SRE workstations running Fedora or Arch, an LPE to root translates directly into theft and abuse of kubeconfigs, cloud credentials, and SSH keys, which often matters more than the host compromise itself.

Mitigation and detection guidance

Security teams should prioritize pulling kernel updates that include both the April 2026 RxGK length‑check fixes and the May 10 aa54b1d27fe0 mitigation before relying on temporary workarounds.

Where patching lags, the same module‑level strategy used for Dirty Frag applies: unload and blacklist esp4, esp6, and rxrpc to stop the vulnerable path, at the cost of breaking IPsec VPNs using ESP and AFS mounts, until a patched kernel is deployed.

Detection is challenging because the exploit uses legitimate kernel paths and leaves few obvious traces in traditional logs.

Practical measures include fleet‑wide sweeps for vulnerable kernel versions and CONFIG_RXGK settings, process‑level monitoring for suspicious modprobe rxrpc invocations, and kernel‑level tracing (via Falco or eBPF‑based tools) around RxGK module loading and unusual UID‑changing activity originating from non‑systemd processes.

Follow us on Google News, LinkedIn, and X to Get Instant Updates and Set GBH as a Preferred Source in Google.