“Dirty Frag” Released Despite Embargo — A New LPE Gaining Root with One Line in Linux Kernel

A single line command grants root access.

And the official kernel release hasn’t even come out yet.

>

What This Article Covers

• The identity and risk level of Dirty Frag (CVE-2026-43284, CVE-2026-43500)
• The operating principle of the exploit chain combining two kernel modules: IPsec ESP and RxRPC
• The weight of the phrase “embargo broken” in the security industry
• Immediate temporary mitigation measures
• The lineage of page cache manipulation: Dirty COW → Dirty Pipe → Copy Fail → Dirty Frag

Linux Kernel, Is It You Again? — A New Chapter in the Page Cache Manipulation Series

On May 7, 2026, a one-line PoC was posted to the Linux security mailing list (oss-security). This is Dirty Frag, a new privilege escalation vulnerability discovered by Korean security researcher Kim Hyun-woo (@v4bel). It scores 7.8 (High) on CVSS 3.1. An unprivileged ordinary user can gain root with a single command.

If these names aren’t familiar, how about these?

• Dirty COW (2016, CVE-2016-5195) — A race condition that shook all Android and Linux systems
• Dirty Pipe (2022, CVE-2022-0847) — Overwriting read-only files via pipes
• ❌ Copy Fail (2026, CVE-2026-31431) — A vulnerability of the same family disclosed just a week ago

And this time, it’s Dirty Frag. Its alias is “Copy Fail 2: Electric Boogaloo”. No joke, that’s what it’s really called.

Dirty Frag, What Exactly Is It?

Dirty Frag is an exploit chain that links two separate kernel flaws.

Flaw 1: xfrm-ESP Page-Cache Write (CVE-2026-43284)

• Location: ESP (Encapsulating Security Protocol) processing module of IPsec (the one used in VPNs)
• Introduced: January 17, 2017 commit
• Trigger condition: Unprivileged users must be able to create namespaces
• In Ubuntu, AppArmor prevents namespace creation, so it doesn’t work alone

Flaw 2: RxRPC Page-Cache Write (CVE-2026-43500)

• Location: RxRPC protocol module used in AFS (Distributed File System)
• Introduced: June 2023 commit
• Trigger condition: No namespace privileges required. However, the rxrpc.ko module itself is missing in some distributions

The core of Dirty Frag is combining these two. If ESP is blocked, it uses RxRPC; if RxRPC is missing, it uses ESP — bypassing defenses depending on the environment. Dirty Frag still works even on systems where Copy Fail mitigations (blocked by algif_aead blacklist) have been applied.

What it Does: Page Cache Overwriting

Linux stores file contents read from disk in RAM’s page cache. This is to reduce the burden of frequently reading the same file. However, this page cache is protected memory. Ordinary users cannot write to it arbitrarily.

Dirty Frag targets code paths where esp4, esp6, and rxrpc ‘decrypt in-place’ page buffers. If pipe pages coming from splice(2) or sendfile(2) reach the socket directly, an unprivileged process can continue to hold a reference to that plaintext page. As a result, a write primitive is created that can overwrite the page cache of read-only system files (e.g., /etc/passwd, /etc/shadow, /usr/bin/sudo).

If you inject root privilege granting code here — that’s it. Unlike race condition-based exploits, this class of bugs is deterministic and highly reliable. This means attempts are very unlikely to fail.

⏰ What Does “Embargo Broken” Mean?

In the security industry, there’s a practice called Coordinated Disclosure. The flow is as follows:

1. Researcher discovers vulnerability
2. Notifies vendor (Linux kernel maintainers) privately
3. Vendor creates a patch and backports it to major distributions
4. Once all preparations are complete, simultaneous public disclosure on the agreed-upon date (embargo lift date)

Here, embargo refers to that agreed-upon period of non-disclosure.

However, with Dirty Frag, this process was broken. The vulnerability’s details were disclosed before the embargo expired, as the fix was reverse-engineered. Someone reversed a patch commit that was merged early into the public git tree, created an exploit, and uploaded it to GitHub. Consequently, while the patch has been incorporated into the mainline kernel, the official kernel release has not yet come out, and most distributions are scrambling to release backported patches.

Breaking an embargo is not merely “leaking a secret.” It means countless systems that haven’t applied the patch will spend days visible to attackers but hidden from defenders.

Affected Distributions

Based on announcements from various vendors, almost all major distributions are affected.

Distribution	Status
Linux Kernel (ESP, ~since 2017)	Affected
Linux Kernel (RxRPC, ~since 2023)	Affected
Ubuntu (multiple versions)	Affected (PoC verified)
RHEL 8 / 9 / 10	Affected
AlmaLinux 8 / 9 / 10	Affected
CentOS Stream 10	Affected
Fedora Latest	Affected
openSUSE Tumbleweed	Affected
OpenShift 4	Potentially Affected

Cloud VMs, bare metal, on-premise workstations — anywhere could be affected.

️ What to Do Right Now

① Apply Kernel Patch (Highest Priority)

If a patch has been released by your distribution, there’s no reason to hesitate.

After updating, you must reboot for the new kernel to take effect.

② If Not Yet Patched, Block Vulnerable Module Loading

⚠️ Caution: Blocking esp4, esp6 will cause IPsec VPNs to stop functioning. Blocking rxrpc will affect AFS distributed file systems. You must verify dependencies before applying this in a production environment.

③ Alternative for Environments Requiring IPsec

If you want to block at least the ESP variant, you can disable unprivileged user namespace creation.

⚠️ However, this measure may affect the operation of rootless containers, sandboxed browsers, and Flatpak, and it does not block the RxRPC variant.

④ Clear Page Cache if Compromise is Suspected

If there are signs of an exploit attempt, you can revert the modified page cache to the original disk content.

Of course, this is only an emergency measure. For systems suspected of compromise, isolation and forensics are the priority.

⚠️ Common Pitfalls

• “We don’t use IPsec on our system” → The RxRPC variant is unrelated to IPsec. It only needs the module to be loadable.
• “We patched Copy Fail last week, so we’re safe” → Copy Fail’s algif_aead blacklist mitigation does not block Dirty Frag. They are separate vulnerabilities.
• “It’s fine because it’s inside a container” → While the risk is reduced in Kubernetes environments with default seccomp profiles, VMs or less restricted environments are still at risk.
• Missing reboot → If you only configure module blocking but don’t reboot, modules already loaded into memory will remain active.

✅ Summary / What This Incident Leaves Us With

• Dirty Frag = CVE-2026-43284 + CVE-2026-43500, CVSS 7.8 (High), page cache manipulation LPE
• IPsec ESP or RxRPC, root possible if only one is exposed
• PoC was released early due to embargo breach, official kernel release is still pending (distributions are backporting)
• Dirty COW → Dirty Pipe → Copy Fail → Dirty Frag — another update in the page cache manipulation lineage
• Immediate actions: ① kernel update, ② if not possible, block modules, ③ verify dependencies and reboot

The page cache is a structure designed for performance. However, the pattern of “if an unprivileged user can somehow manipulate that page, privilege escalation occurs” is now the fourth instance. Wouldn’t you bet about 10,000 won that the next disclosure will be of the same family?