DirtyDecrypt: PoC Released for Linux Kernel RxGK Root Escalation—CONFIG_RXGK Targets at Risk
DirtyDecrypt Linux kernel vulnerability (CVE-2026-31635) now has working PoC exploit for root escalation. Targets systems with CONFIG_RXGK enabled (AFS support). Affects rolling-release distros. Part of recent "Dirty*" vulnerability wave—patch or blacklist modules immediately.
What's Happening
A new privilege escalation vulnerability in the Linux kernel's RxGK module (part of the RxRPC network transport layer) now has a proof-of-concept exploit. The flaw, dubbed DirtyDecrypt (also called DirtyCBC), allows unprivileged attackers to gain root access under specific conditions.
The V12 Security team discovered and reported this vulnerability on May 9, 2026. They were told by maintainers it was a duplicate of a previously patched issue—specifically CVE-2026-31635, which was patched in the mainline kernel on April 25.
The bug: Missing copy-on-write (COW) guard in rxgk_decrypt_skb() causes page cache corruption in the rxgk module, allowing local privilege escalation.
Scope: Limited to systems that have CONFIG_RXGK enabled in the kernel config. This includes AFS (Andrew File System) support and RxGK security features. Not enabled by default on most enterprise distributions, but present in rolling-release distros that track mainline closely.
Who's Affected
High risk:
- Fedora (all releases with CONFIG_RXGK enabled)
- Arch Linux
- openSUSE Tumbleweed
PoC tested on Fedora and mainline only. Other distros may be affected if they compile CONFIG_RXGK in.
Lower risk:
- Ubuntu, Debian, CentOS, RHEL (typically ship without CONFIG_RXGK in standard kernels; check with:
grep CONFIG_RXGK /boot/config-$(uname -r)) - Enterprise distributions (custom kernel configs usually disable experimental networking features)
⚠️ Check your config: If you're unsure:
grep CONFIG_RXGK /boot/config-$(uname -r)
If output is CONFIG_RXGK=y or CONFIG_RXGK=m, you're potentially vulnerable. If CONFIG_RXGK=n or file doesn't exist, you're not.
Technical Details
Vulnerability class: Page cache corruption via missing COW guard.
Trigger: Exploiting the rxgk_decrypt_skb() function in the RxRPC module to corrupt memory when decrypting packets. Because there's no proper copy-on-write protection, attackers can manipulate page cache entries and escalate privileges.
Impact: Local unprivileged user → root.
Related vulnerabilities: This is part of a recent wave of similar kernel memory-corruption flaws:
- Dirty Frag (CVE-2026-43284, CVE-2026-43500)
- Fragnesia (CVE-2026-46300)
- Copy Fail (CVE-2026-32202) — already exploited in the wild; CISA added to known-exploited list May 1; federal agencies ordered to patch by May 15
Mitigation & Patching
Patch (Preferred)
Update your kernel to the latest version:
Fedora:
dnf upgrade kernel
reboot
Arch:
pacman -Syu linux
reboot
openSUSE Tumbleweed:
zypper dup
reboot
Others: Check your distro's update mechanism. Mainline patch is in the tree; most distros will backport within 1–2 weeks.
Temporary Mitigation (If Patching Delayed)
Blacklist the vulnerable modules:
sh -c "printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/dirtydecrypt.conf; rmmod esp4 esp6 rxrpc 2>/dev/null; echo 3 > /proc/sys/vm/drop_caches; true"
⚠️ WARNING: This breaks:
- IPsec VPN (ESP4/ESP6 modules)
- AFS distributed file systems (rxrpc module)
- Any application relying on RxRPC kernel support
Only use this if you're certain you don't need those features, and patching is genuinely delayed beyond 1–2 weeks.
Verify Module is Blacklisted
lsmod | grep -E "esp4|esp6|rxrpc"
Should return empty. If modules still load, verify blacklist is in /etc/modprobe.d/ and reload:
systemctl reboot
Detection
Check if you've been exploited:
ausearch -k privilege_escalation 2>/dev/null | tail -20
journalctl -p err -x | grep -i segfault
dmesg | grep -i "page cache\|memory corruption"
Monitor for exploitation attempts:
- Unusual unprivileged process spawning SUID binaries
- Abnormal memory access patterns in system logs
- Unexpected root-owned processes from standard user sessions (check auth logs)
⚠️ If this distro is internet-facing and not yet patched: Assume compromised if it's been running unpatched for >1 week with unprivileged user access.
Hardening (Post-Patch)
- Audit kernel config: Disable CONFIG_RXGK in custom kernels if AFS not in use
- Restrict unprivileged access: Use AppArmor/SELinux to limit what unprivileged users can execute
- Monitor system calls: Use auditd to log privilege escalation attempts:
auditctl -w /etc/sudoers -p wa -k privilege_escalation
Context: The "Dirty*" Vulnerability Wave
This is the fourth major privilege escalation flaw disclosed in recent weeks, all in similar memory-corruption classes:
- Dirty Frag (April 2026): Page cache + hard-link corruption
- Fragnesia (May 2026): XFRM ESP-in-TCP logic bug
- Copy Fail (May 2026): memmove/copy_from_user race condition — actively exploited in production
- DirtyDecrypt (May 2026): RxGK page cache COW missing guard
Pattern: All are local LPE; all require specific kernel features enabled; all impact rolling-release distros. Suggests attackers are systematically probing kernel subsystems for similar patterns.
What's Next
- Patches will land in distro updates within 1–2 weeks for Fedora/Arch/openSUSE; longer for enterprise distros
- Expect exploitation attempts on systems that don't patch immediately (similar to Copy Fail trajectory)
- Copy Fail remains the highest priority for patching since it's already being exploited in attacks
References
- V12 Security GitHub: DirtyDecrypt PoC (poc.c, details in repo)
- CVE-2026-31635: NIST NVD entry (patched April 25, mainline)
- CISA Known Exploited Vulnerabilities: Copy Fail (CVE-2026-32202) added May 1
- Will Dormann (Tharros): CVE-2026-31635 analysis
- Linux kernel RxRPC/RxGK docs: https://docs.kernel.org/networking/rxrpc.html
- Related: Dirty Frag, Fragnesia, Copy Fail disclosure timeline