Dirty Frag: A New Linux Exploit With No Patch and a Public Proof-of-Concept

A newly disclosed Linux kernel vulnerability is already being exploited in the wild – and no official patches exist yet. Here’s what Dirty Frag is, who’s affected, and what you can do right now.

A new Linux privilege escalation vulnerability called Dirty Frag was publicly disclosed on 7 May 2026 after its embargo was broken by an unrelated third party. It affects most major Linux distributions running kernels from 2017 onwards, and a working public exploit already exists. As of this writing, no official distribution patches have been released.

Dirty Frag was discovered and reported by researcher Hyunwoo Kim (@v4bel). It belongs to the same vulnerability class as Dirty Pipe (CVE-2022-0847) and the more recent Copy Fail (CVE-2026-31431) – both of which we have covered previously. Like those, Dirty Frag exploits a path through the Linux kernel’s page cache that allows an unprivileged user to overwrite files they only have read access to, such as /etc/passwd or /usr/bin/su, and escalate to root.

What is Dirty Frag?

Dirty Frag works by chaining two separate page-cache write vulnerabilities in the Linux kernel’s networking stack:

1. xfrm-ESP Page-Cache Write – The IPsec ESP input path (esp_input()) should copy any attacker-controlled page data to a private kernel buffer before performing in-place cryptographic decryption. A logic flaw allows it to skip that copy when the socket buffer has no fragment list, meaning crypto operations write directly on top of a page cache page the attacker has planted via splice(). This gives the attacker an arbitrary 4-byte write primitive at any position in any file they can read, with the write value controlled via a netlink attribute set at SA registration time. This variant has been present in the kernel since January 2017.

2. RxRPC Page-Cache Write – The Andrew File System’s RxRPC protocol performs an in-place single-block decryption on incoming packet data without first checking whether the socket buffer references externally pinned pages. An attacker can again plant a page cache page via splice(), then trigger an 8-byte overwrite at a chosen offset using a key they register themselves. This variant has been present since June 2023 and – critically – does not require any special privileges to trigger.

The two variants are chained together because each covers the other’s blind spot. The ESP variant requires the ability to create a user namespace (which Ubuntu sometimes restricts via AppArmor), while the RxRPC variant requires the rxrpc.ko kernel module to be present (which most distributions don’t ship, but Ubuntu loads by default). Together, a single exploit binary achieves root on essentially every major distribution.

Affected Distributions

The exploit has been confirmed working on all of the following:

Any Linux kernel from commit cac2661c53f3 (17 January 2017) onwards is affected by the ESP variant. The RxRPC variant additionally requires commit 2dc334f1a63a (June 2023) or later. The combined effective exposure window for the full chain is approximately 9 years.

Patch Status

Because the disclosure embargo was broken early, no distribution has had time to prepare and ship patches. Here is the current status:

Watch your distribution’s security advisory feed for backported patches. We will update this post when packages are available.

What To Do Now

Until distribution patches are available, the recommended mitigation is to disable the kernel modules in which the vulnerabilities occur. The following command disables esp4, esp6, and rxrpc, prevents them from loading on next boot, and attempts to remove them from the running kernel:

The esp4/esp6 modules handle IPsec ESP – if you are running IPsec VPN tunnels (site-to-site or road warrior), disabling these modules will break that connectivity. Weigh this against your exposure profile. The rxrpc module is used only by the Andrew File System (AFS), which is rarely deployed in production environments.

Once your distribution releases a patched kernel, apply it and reboot. You can then remove the /etc/modprobe.d/dirtyfrag.conf workaround file if the affected modules are needed.

Disclosure Timeline

How Serious Is This?

Dirty Frag is a local privilege escalation – exploit it, an attacker must already have a shell or code execution on your system as a non-root user. It cannot be triggered remotely on its own. However, LPE vulnerabilities are a critical step in the standard attack chain: an attacker who gains initial access via a web application, SSH brute force, or any other vector can use Dirty Frag to immediately become root, regardless of what other hardening is in place.

For shared hosting environments and multi-tenant servers in particular, this is a high-priority item. Any user account with shell access – including compromised application accounts, untrusted developers, or malicious tenants – could use this to escape their privilege boundary and take full control of the host.

References

• Dirty Frag — GitHub (V4bel/dirtyfrag) – PoC, write-up, and mitigation command
• ESP fix — netdev kernel.org commit – merged 7 May 2026
• RxRPC patch — netdev mailing list – submitted, pending merge
• Shared-frag patch (Kuan-Ting Chen) — netdev mailing list
• Dirty Pipe (CVE-2022-0847) – predecessor vulnerability
• Copy Fail (CVE-2026-31431) – predecessor vulnerability