Dirty Frag Explained: Linux Root Exploit, Mitigation & Patching Guide

Go straight to an AI summary of this blog post instead

Looking for mitigation steps? Jump ahead ↓

The Short Version

What: A Linux local privilege escalation chain dubbed Dirty Frag, combining CVE-2026-43284 (xfrm-ESP page-cache write) and CVE-2026-43500 (RxRPC page-cache write).
Impact: Public proof-of-concept exploits demonstrate reliable root privilege escalation from an unprivileged local account on vulnerable kernels.
Status: Working public exploits are circulating. The embargo broke before coordinated patching completed.
Severity: Local attack vector, low complexity, no user interaction, deterministic exploitation. CVSS: 7.8 (provisional)
Do this now: Protect affected kernels immediately. Rebootless patching mitigates Dirty Frag without waiting for maintenance windows or reboots. Otherwise, deploy patched kernels as soon as possible. If neither is immediately available, temporarily disable the vulnerable ESP and RxRPC paths below.

Am I Affected?

You are likely affected if you run a recent mainline-derived kernel on any of:

Ubuntu (LTS and current releases)
Red Hat Enterprise Linux, AlmaLinux, Rocky Linux, CentOS Stream
Fedora
openSUSE Tumbleweed
Most downstream rebuilds, including CloudLinux variants

Quick check for the exposed modules:

lsmod | grep -E '^(esp4|esp6|rxrpc) '

If any of these are loaded – or can be auto-loaded on demand by an unprivileged user – you should treat the host as exposed until patched.

You are not automatically safe just because you applied earlier Copy Fail mitigations. Blocking algif_aead does not stop Dirty Frag.

What Dirty Frag Is

Dirty Frag is a kernel local privilege escalation (LPE) chain that abuses two in-place decryption paths in the Linux network stack:

xfrm-ESP (esp4, esp6), used by IPsec
RxRPC (rxrpc), used by AFS and related RPC traffic

It belongs to the same family of bugs as Dirty Pipe and Copy Fail: a kernel routine writes data into a page that it does not exclusively own, ending up clobbering the contents of a page-cache entry that backs a file on disk.

The chain was disclosed by researcher Hyunwoo Kim. ‘Copy Fail 2: Electric Boogaloo’ is the xfrm-ESP half of Dirty Frag (CVE-2026-43284), reverse-engineered from the public fix commit – not a separate CVE and not the full chain.

How the Exploit Actually Works

The Linux page cache holds in-memory copies of file contents so that repeated reads do not have to hit the disk. When you cat /etc/passwd, the kernel almost always serves you bytes from a cached page rather than from the filesystem. That cached page is shared: every reader of that file sees the same memory.

Modern kernel receive paths support zero-copy decryption. When encrypted network data arrives – for example, an ESP-encapsulated IPsec packet – the kernel can decrypt it directly into a destination page rather than allocating a fresh buffer and copying twice. This is fast, and for most destinations it is safe, because the destination page is something the kernel allocated for that purpose.

Dirty Frag arises when the destination page is not privately owned. Through carefully constructed splice(2) or sendfile(2) operations, an unprivileged process can arrange for the kernel’s ESP or RxRPC receive path to decrypt incoming data directly into a page that is currently serving the page cache – including pages backing sensitive files such as /etc/passwd or /usr/bin/su.

The decrypted bytes are attacker-controlled (the attacker chose the plaintext before encrypting and sending it). Because the kernel does not COW or otherwise isolate the destination page, the write lands in the shared page-cache copy. Subsequent reads of the file – including reads by login, sudo, or su – return the modified contents.

The on-disk file is unchanged. However, subsequent reads may consume the modified cached version instead of the original filesystem contents.

Two paths are chained for distribution coverage:

The ESP path needs unprivileged user namespace creation, which Ubuntu blocks via AppArmor but most other distros allow.
The RxRPC path needs the rxrpc.ko module to be loaded, which most distributions don’t ship by default – but Ubuntu does. Ubuntu’s namespace block is covered by RxRPC; everyone else’s missing rxrpc is covered by ESP.

Together they cover most common hardening configurations.

What makes the bug unusually dangerous in practice:

Deterministic: No race window, no timing-sensitive primitive.
Quiet on failure: Failed attempts do not typically panic the kernel.
High success rate: Reliable enough that the public PoC works as a one-shot.
Rapid weaponization: Public exploit chains appeared before coordinated patching completed, shrinking defender response time dramatically.

Mitigation

The safest remediation path is protecting the running kernel immediately. There are three practical ways to reduce exposure, listed here in order of speed and operational impact.

1. Rebootless patching (fastest, no downtime)

KernelCare rebootless patches are rolling out for affected enterprise kernel families, allowing vulnerable running kernels to be protected without waiting for emergency maintenance windows or coordinated reboots.

For organizations operating uptime-sensitive infrastructure, this reduces remediation time immediately while standard vendor kernel rollouts and reboot cycles catch up.

As additional downstream kernel package versions are released, scanner detection and vendor version reporting may temporarily lag behind the protected running kernel state.

Not a KernelCare customer yet? New-customer pricing is discounted through the end of June. Learn more about KernelCare here.

2. Install a patched kernel and reboot

The standard remediation path is deploying vendor-supplied patched kernel packages and rebooting affected systems as soon as operationally possible.

Prioritize systems where partially trusted code can execute – including Kubernetes nodes, CI/CD runners, shared hosting environments, developer infrastructure, and multi-tenant workloads.

3. Temporary manual mitigation (if patching must wait)

If neither rebootless patching nor immediate reboot windows are available, the vulnerable ESP and RxRPC paths can be temporarily disabled through module blocking.

Read this first

Blocking esp4 and esp6 will break IPsec. If you terminate or route IPsec traffic – strongSwan, Libreswan, site-to-site VPNs, or road-warrior clients – applying this on production hosts will drop those tunnels.

Before deploying broadly, confirm the modules are not actively in use.

ip xfrm policy list 2>/dev/null | head
ss -tunap | grep -i rxrpc

If output is non-empty, plan around the impact before proceeding.

Block the vulnerable modules

sudo sh -c "printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/dirtyfrag.conf; rmmod esp4 esp6 rxrpc 2>/dev/null; true"

If compromise is suspected

Drop the page cache so any modified cached binaries are evicted and re-read from disk on next access:

sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'

Treat this as a forensic step, not a fix. If an attacker has already gained root via Dirty Frag, page-cache eviction does not remove anything they did after escalation.

Detection

There is currently no widely accepted or reliable post-hoc detection method for confirming successful Dirty Frag exploitation. The on-disk files are untouched, and the attack leaves no syscall pattern as distinctive as Dirty Pipe’s. That said, a few signals are worth hunting for:

Unexpected loading of esp4, esp6, or rxrpc on hosts that have no business with IPsec or AFS. Auditd rule:

-w /sbin/modprobe -p x -k module_load

New unprivileged-user creation of network namespaces on systems where this is not part of normal workload. Trace via unshare syscalls or eBPF.
Setuid execution by accounts that have never previously invoked su or sudo, particularly shortly after splice/sendfile-heavy activity.
Imunify360 customers: indicators tied to the public PoC’s deployment script have been added to its blocklist.

These are heuristics, not guarantees. Assume any host where an untrusted local user had shell access during the exposure window is potentially compromised.

Prioritized Remediation Checklist

Patch: Apply a rebootless patch or deploy a patched kernel immediately. KernelCare users can protect supported running kernels without rebooting while standard maintenance windows catch up. Otherwise, install vendor-patched kernels and reboot affected systems as soon as possible.
If you cannot patch immediately, apply the module-blocking mitigation above – after confirming you do not depend on IPsec or RxRPC.
Audit local access: Review who currently has shell on shared hosts, CI/CD runners, build servers, and multi-tenant systems. Revoke what is not needed for the duration.
Hunt: Run the detection queries above against the exposure window.
Reboot after patching: This will flush any potentially modified cached pages along with the old kernel.

Why Bugs Like Dirty Frag Are Appearing Faster

Dirty Frag also reflects a broader industry trend: AI-assisted auditing is accelerating the discovery of deep, long-lived flaws in performance-critical code paths.

In a recent post, TuxCare CEO Igor Seletskiy argued that modern AI-assisted analysis is collapsing the time required to uncover subtle kernel and infrastructure vulnerabilities that previously survived years of review.

Dirty Frag fits that pattern closely: a page-cache ownership flaw hidden inside high-performance networking paths, now weaponized into reliable privilege escalation with public exploit code already circulating.