DirtyDecrypt Linux kernel exploit code released for local root escalation flaw

Proof-of-concept exploit code is now public for DirtyDecrypt, also known as DirtyCBC, a Linux kernel local privilege escalation issue that can give a local attacker root access on some affected systems.

The flaw affects the RxGK path in the Linux kernel’s RxRPC subsystem, which supports security for the Andrew File System client transport. Successful exploitation requires local code execution first, so this is not a remote attack by itself.

The risk still matters because attackers often use local privilege escalation bugs after gaining an initial foothold through SSH access, a web shell, a compromised container, or a low-privileged service account. Once the exploit works, the attacker can move from limited access to root on the host.

What DirtyDecrypt does

DirtyDecrypt targets a kernel code path involving rxgk_decrypt_skb(), the function that decrypts incoming socket buffer data in the RxGK subsystem.

The issue involves missing copy-on-write protection during a decrypt operation. In simple terms, the kernel can write into memory that should not be modified directly, including page-cache-backed data.

That page-cache corruption can affect privileged files or data used by higher-privileged processes. Public analysis links this behavior to the same wider bug family as Copy Fail, Dirty Frag, and Fragnesia, where kernel performance optimizations around zero-copy or in-place operations cross a security boundary.

Item	Details
Name	DirtyDecrypt, also called DirtyCBC
Public CVE association	CVE-2026-31635, with attribution caveats
Bug type	Local privilege escalation through page-cache corruption
Affected area	Linux kernel RxGK and RxRPC code path
Required access	Local unprivileged code execution
Possible impact	Root access on vulnerable systems
Exploit status	Public PoC available

The CVE picture is confusing

DirtyDecrypt has been publicly linked to CVE-2026-31635, but administrators should understand the mismatch before relying on that identifier alone.

NVD’s description for CVE-2026-31635 focuses on an oversized RESPONSE authenticator length check in rxgk_verify_response(). That description points to a denial-of-service condition where the kernel can hit BUG_ON(len).

The DirtyDecrypt PoC, however, targets a local privilege escalation path involving page-cache writes in rxgk_decrypt_skb(). Public reporting connects the two because the NVD record includes a link to the DirtyDecrypt PoC, while some analysis says the LPE variant does not have a clean formal CVE alias of its own.

Who is most exposed?

DirtyDecrypt requires kernels built with CONFIG_RXGK enabled, either built in or available as a module. That narrows the practical attack surface compared with bugs present in every default Linux installation.

The highest-risk systems are likely rolling-release or upstream-tracking Linux deployments. Public reports mention Fedora, Arch Linux, openSUSE Tumbleweed, mainline kernels, and similar fast-moving environments as the main exposure group.

Stable enterprise distributions may be less exposed by default if RxGK is disabled or not present, but administrators should not assume safety from distribution name alone. Kernel configuration, vendor backports, live patches, and loaded modules matter more than marketing labels.

Environment	Risk level	Reason
Fedora, Arch Linux, openSUSE Tumbleweed	Higher	These distributions often track newer upstream kernel code faster
Mainline kernel builds	Higher	Users may run affected code before vendor hardening or backports
Kubernetes worker nodes on rolling kernels	High	Root on the host can expose containers, secrets, and runtime sockets
Developer workstations	Medium to high	They often store SSH keys, cloud profiles, kubectl contexts, and source access
Stable enterprise Linux builds	Varies	Exposure depends on kernel config and vendor patches

Why local privilege escalation bugs matter

Local privilege escalation vulnerabilities often look less urgent than remote code execution bugs because the attacker needs an initial foothold first.

In real intrusions, that foothold is often already available. Attackers may enter through stolen SSH credentials, a compromised web application, a malicious CI job, a container escape setup, or a low-privileged user account.

After that, an exploit like DirtyDecrypt can become the step that turns limited access into full control of the system. Root access can let attackers disable defenses, read secrets, modify logs, install persistence, and pivot to other systems.

Why containers and Kubernetes increase the risk

Container environments deserve special attention because many workloads share the same kernel. If an attacker can run code in a vulnerable local context and reach the affected kernel path, root on the host can become a broader infrastructure problem.

On a Kubernetes worker node, host-level root access can expose container runtime sockets, mounted secrets, service account tokens, pod data, and node-level credentials.

This does not mean every container can exploit DirtyDecrypt. The practical risk depends on kernel configuration, namespace restrictions, loaded modules, security profiles, and what the container can access. Still, organizations running untrusted workloads should prioritize patching worker nodes.

How to check for possible exposure

Administrators should first check whether the kernel has RxGK support enabled. On systems that expose the kernel config through /proc/config.gz, the following command can help:

zcat /proc/config.gz | grep RXGK

If the system does not expose /proc/config.gz, check the boot configuration file for the running kernel:

grep RXGK /boot/config-$(uname -r)

A result showing CONFIG_RXGK=y or CONFIG_RXGK=m means the system may have the relevant support built in or available as a module. Administrators should then confirm whether their vendor kernel includes the relevant fixes.

Patch first where possible

The safest fix is to install the latest kernel update from the Linux distribution vendor and reboot into the patched kernel.

Because distribution maintainers often backport fixes, administrators should not rely only on upstream version numbers. A vendor kernel can include the fix while still carrying an older version string.

Systems with public PoC exposure, multi-user access, container workloads, developer secrets, or internet-facing services should move to the front of the patching queue.

# Fedora
sudo dnf upgrade --refresh kernel kernel-core kernel-modules
sudo reboot

# Arch Linux
sudo pacman -Syu linux linux-headers
sudo reboot

# openSUSE Tumbleweed
sudo zypper dup
sudo reboot

Temporary mitigations have trade-offs

If patching cannot happen immediately, administrators can reduce exposure by blocking affected or related modules. Public guidance around the Dirty Frag family often recommends disabling rxrpc, esp4, and esp6 as a temporary step.

This workaround can break real workloads. Disabling esp4 and esp6 can affect IPsec VPNs. Disabling rxrpc can affect AFS-related environments. Teams should test the impact before applying the change broadly in production.

Temporary mitigations should not replace kernel updates. They only buy time until the system can boot into a patched kernel.

sudo tee /etc/modprobe.d/dirtydecrypt-mitigation.conf > /dev/null <<'EOF'
install rxrpc /bin/false
install esp4 /bin/false
install esp6 /bin/false
blacklist rxrpc
blacklist esp4
blacklist esp6
EOF

sudo rmmod rxrpc esp4 esp6 2>/dev/null || true
sudo reboot

What defenders should monitor

DirtyDecrypt exploitation starts after local code execution, so defenders should watch for signs of suspicious local activity before and after privilege escalation.

Useful signals include unexpected compilation or execution of unknown ELF files, suspicious access to kernel attack surface modules, privilege changes followed by su or sudo activity, and sudden modification of sensitive files or SUID binaries.

Organizations should also watch developer and CI systems carefully. These machines often hold cloud credentials, SSH keys, deployment tokens, and Kubernetes access that become more dangerous after root compromise.

• Unknown ELF binaries executed from /tmp, /dev/shm, or user-writable directories.
• Unexpected local users gaining root shortly after running unusual binaries.
• Kernel module loading involving rxrpc, esp4, or esp6 on systems that do not normally use them.
• Suspicious access to /etc/shadow, /etc/sudoers, or SUID binaries.
• Container workloads attempting unusual kernel or network operations.
• New persistence files created immediately after privilege escalation.
• Security tools being stopped or logs being modified after local process execution.

How DirtyDecrypt fits the recent Linux bug wave

DirtyDecrypt follows a series of Linux local privilege escalation disclosures tied to page-cache and in-place operation weaknesses.

Copy Fail affected the AF_ALG crypto path. Dirty Frag expanded the issue into networking and memory-fragment handling through xfrm ESP and RxRPC paths. Fragnesia affected the XFRM ESP-in-TCP subsystem.

DirtyDecrypt adds another example from the same broader class: kernel code optimized for performance writes into memory that should have remained isolated. These bugs show why copy-on-write boundaries, shared fragments, and page-cache ownership must be handled with extreme care.

Vulnerability family	Main area	Impact
Copy Fail	AF_ALG crypto API	Local privilege escalation through page-cache corruption
Dirty Frag	xfrm ESP and RxRPC paths	Local privilege escalation through shared fragment handling
Fragnesia	XFRM ESP-in-TCP	Local privilege escalation through page-cache writes
DirtyDecrypt	RxGK and RxRPC decrypt path	Local privilege escalation on systems with CONFIG_RXGK enabled

What organizations should do now

Security teams should treat DirtyDecrypt as urgent on systems where untrusted local code can run. That includes shared servers, CI runners, developer workstations, lab machines, Kubernetes workers, and multi-tenant Linux environments.

Single-user systems with no untrusted local workloads face lower practical risk, but they should still receive kernel updates. Public PoC code reduces the skill barrier for attackers who already have access.

After patching, teams should reboot and verify the active kernel, not only the installed package. A patched kernel sitting on disk does not protect a running system until the machine boots into it.

1. Check whether CONFIG_RXGK is enabled on Linux systems.
2. Prioritize Fedora, Arch, openSUSE Tumbleweed, mainline kernels, and Kubernetes worker nodes.
3. Install the latest vendor kernel update.
4. Reboot into the patched kernel.
5. Apply temporary module blocking only if patching must be delayed.
6. Confirm whether IPsec, AFS, or RxRPC-dependent services need exceptions.
7. Hunt for suspicious local privilege escalation behavior.
8. Rotate credentials if a vulnerable host may have been compromised.

FAQ