Dirty Frag: Root Access on Every Major Linux Distribution — No Patch, No Warning

Just one week after the “Copy Fail” vulnerability rattled the Linux security community, researcher Hyunwoo Kim has disclosed a second critical local privilege escalation (LPE) bug — dubbed Dirty Frag — that affects virtually all major Linux distributions shipped since 2017. Unlike many vulnerabilities that require specific timing, elevated privileges, or lucky race conditions, Dirty Frag is a pure logic flaw: it works deterministically, on the first try, on any system with the vulnerable kernel modules loaded.

The vulnerability’s disclosure was forced earlier than planned. The embargo — originally set to expire on May 12, 2026 — was broken by an unrelated third party who published the ESP exploit publicly on May 7. Kim, in consultation with the linux-distros maintainers, immediately released the full technical write-up and proof-of-concept to avoid an information asymmetry in which attackers had working exploit code but defenders had no guidance.

What Is Dirty Frag?

Dirty Frag belongs to the same exploit class as Dirty Pipe (CVE-2022-0847) and the recent Copy Fail (CVE-2026-31431). The name refers to the technique of “dirtying” the frag member of the kernel’s struct sk_buff — the core socket buffer data structure — to achieve an arbitrary write into pages that the kernel should never modify.

“Dirty Frag allows immediate root privilege escalation on all major distributions, and chains two separate vulnerabilities. Because the embargo has been broken, no patches or CVEs exist.”
— Hyunwoo Kim, oss-security mailing list, May 8, 2026

The key characteristic that makes Dirty Frag especially alarming is its reliability. It does not rely on a race condition, does not cause kernel panics on failed attempts, and requires no special privileges, kernel module compilation, or system-specific knowledge. Any user with a shell can run the proof-of-concept.

Technical Details

The Two Chained Vulnerabilities

Dirty Frag is not a single bug — it chains two distinct kernel flaws to cover all major distributions, working around per-distro mitigations:

Because Ubuntu’s AppArmor can block Bug 1 by restricting unprivileged user namespace creation, the proof-of-concept automatically falls back to Bug 2 — the RxRPC path — ensuring root is achieved regardless of the AppArmor configuration. Neither vulnerability alone covers every distribution; together, they leave no major distro unaffected.

Relationship to Copy Fail

Dirty Frag shares the same exploit “sink” as Copy Fail — the xfrm-ESP path. Critically, it bypasses Copy Fail’s primary mitigation: blacklisting the algif_aead module. Systems that applied only that mitigation after Copy Fail remain fully vulnerable to Dirty Frag’s ESP path.

Affected Distributions

The vulnerability has been confirmed exploitable on all of the following. The effective impact window spans approximately nine years of Linux kernel history.

Note: “Ubuntu 26” referenced in some early reports does not exist as of this writing. The confirmed affected Ubuntu releases are LTS versions 22.04 and 24.04, as well as interim releases with kernels in the affected range.

Disclosure Timeline

Patch Status

As of May 8, 2026, no CVE has been assigned and no widely distributed kernel patch exists for mainstream distributions. The situation is actively evolving:

Mitigation: Disable the Vulnerable Modules

Until kernel patches are available for your distribution, the recommended mitigation is to blacklist and unload the three kernel modules that contain the vulnerable code paths. For most servers and desktops, these modules — esp4, esp6, and rxrpc — are not actively used and can be safely disabled.

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"

This command does two things: it writes a modprobe blacklist that prevents the modules from loading on future boots, and it attempts to unload them from the currently running kernel. The 2>/dev/null; true portion ensures the command exits cleanly even if the modules are not currently loaded.

To verify the mitigation was applied successfully, check that none of the modules appear in the output of:

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

No output means the modules are not loaded and the system is mitigated.

Caveats Before Applying

Disabling these modules will break the following workloads: IPsec VPN tunnels using ESP mode (esp4/esp6) and AFS distributed file systems using the kernel RxRPC implementation (kAFS). It does not affect OpenAFS, which is the more common AFS implementation in enterprise environments. Organizations running IPsec-based VPNs should evaluate the tradeoff carefully and may need to wait for a kernel patch while monitoring their environment closely.

Risk Assessment

What You Should Do Now

1. Apply the module mitigation immediately using the command above, unless your systems depend on IPsec ESP or kAFS. This is the only available protection for most distributions right now.

2. Subscribe to your distribution’s security advisories to receive notification when backported kernel patches become available. For RHEL-based systems, monitor Red Hat’s security advisories; for Ubuntu, watch Ubuntu Security Notices.

3. Audit access controls on any multi-user or shared system. Dirty Frag requires a local unprivileged user account — review who has shell access to your systems.

4. Do not rely solely on the Copy Fail mitigation. Blacklisting algif_aead does not protect against Dirty Frag’s exploit chain.

5. Once patches are available, apply and reboot immediately. Module blacklisting is a temporary workaround — it does not fix the underlying kernel vulnerability.

Further Reading

The full technical write-up, proof-of-concept code, and disclosure timeline have been published by Hyunwoo Kim at the official GitHub repository: github.com/V4bel/dirtyfrag. The original oss-security disclosure is available at the Openwall mailing list archive.