A working proof-of-concept is now public for DirtyDecrypt (also tracked as DirtyCBC), a Linux kernel local privilege escalation bug that hands an unprivileged user full root on any system built with the RxGK security layer enabled. The flaw is CVE-2026-31635 (CVSS 7.5). The identifier was never formally announced — researchers inferred it from the NVD record, which links directly to the PoC — but the fix is already in the mainline tree, so this is n-day weaponization, not a zero-day. If you run Fedora, Arch, or openSUSE Tumbleweed, treat it as exploitable today.
What broke
The fault sits in rxgk_decrypt_skb(), the function that decrypts an incoming sk_buff (socket buffer) on the receive side of RxGK — the GSS-API-based security layer for RxRPC, the network transport used by the Andrew File System (AFS) client. On this code path the kernel touches memory pages that are partly shared with the page cache of other processes. That sharing is a normal Linux optimization, and it is supposed to be protected by copy-on-write: the moment something writes to a shared page, the kernel makes a private copy first so the write cannot bleed into another process’s data.
DirtyDecrypt is the absence of that COW guard. Decryption writes straight into the shared page without cloning it, so the plaintext lands in memory it should never reach — the address space of a privileged process, or the cached pages of a privileged file. From there the exploit is the same well-worn move the rest of this bug class uses: overwrite /etc/shadow, /etc/sudoers, or a setuid binary’s cached pages and walk up to root. No on-disk artifacts, no crash, just a quiet write into the page cache.
It was found and reported by the Zellic and V12 team on May 9, 2026. The maintainers came back and told them it was a duplicate of a bug already silently patched upstream — which is exactly why a public PoC matters now. The fix landed without fanfare, plenty of running kernels have not pulled it, and the working exploit closes the gap between “quietly fixed” and “trivially abused.”
Who is affected
DirtyDecrypt only bites kernels compiled with CONFIG_RXGK (=y or =m). In practice that means Fedora, Arch Linux, and openSUSE Tumbleweed, which ship it enabled. Debian Stable, RHEL 8/9, and Ubuntu LTS disable RxGK by default and are not affected out of the box — confirm your own build rather than assuming.
The container story is the part worth losing sleep over. Pods share the host kernel and its page cache, so a vulnerable worker node turns a single compromised container into a pod-escape and node-takeover primitive. Multi-tenant Kubernetes clusters and CI/CD runners that execute untrusted code are the highest-value targets here.
DirtyDecrypt is the fourth public member of a page-cache LPE family that has piled up since late April: Copy Fail (CVE-2026-31431, the algif_aead crypto interface), Dirty Frag / Copy Fail 2 (CVE-2026-43284 and CVE-2026-43500), and Fragnesia (CVE-2026-46300, XFRM ESP-in-TCP). Same root cause every time — a kernel write into shared or page-cache pages with no copy-on-write — just a different subsystem reaching it.
What to do now
Patch the kernel. The fix is upstream, so pull your distribution’s current kernel update and reboot; prioritize Kubernetes worker nodes and build runners exposed to untrusted workloads. If you cannot patch immediately, check whether RxGK is even present — grep RXGK /boot/config-$(uname -r) — and if you do not use AFS, keep the rxrpc module from loading (blacklist rxrpc plus install rxrpc /bin/true in modprobe config) to remove the attack surface entirely. The broader fire drill has the kernel community reviewing Sasha Levin’s runtime “killswitch” proposal for neutering a vulnerable function until a real fix ships, and Rocky Linux has stood up an opt-in security repository for exactly this “public exploit, no upstream fix yet” window.