Eight days after Copy Fail, here we are again.
Dirty Frag is a Linux kernel local privilege escalation chain disclosed on May 7 by Hyunwoo Kim. Two CVEs: CVE-2026-43284 in the xfrm-ESP module, and CVE-2026-43500 in RxRPC. Both are page-cache write primitives. Chained together, they hand an unprivileged local user root on every major distribution that hasn’t backported the fix.
That’s the technical summary. The interesting part of this story isn’t the bugs. It’s the disclosure timeline.
What it does
Each bug independently writes attacker-controlled bytes into the kernel’s page cache without touching the underlying file on disk. The exploit picks a target file the kernel has cached, overwrites a few bytes in that cached copy, and now every process that reads that file sees the attacker’s version.
Path one. The xfrm-ESP variant uses the ESP-in-UDP MSG_SPLICE_PAGES no-COW fast path reachable via XFRM netlink to land an arbitrary 4-byte STORE primitive into any cached page. The PoC overwrites the page-cache copy of /usr/bin/su with an embedded x86_64 root shell ELF and bypasses PAM entirely.
Path two. The RxRPC variant achieves a similar page-cache write through rxkad authentication and does not need a network namespace to set up. The PoC modifies /etc/passwd so the root entry has no password, then runs su against PAM nullok.
Kim describes the chain as deterministic: no race condition, no timing window, no kernel panic on failure. If this sounds familiar, it should. Copy Fail had the same shape. Kim says directly that Dirty Frag “extends the bug class to which Dirty Pipe and Copy Fail belong”.
The Copy Fail mitigation does not save you
The Copy Fail mitigation was easy. Block the algif_aead module. Almost nothing real used AF_ALG. Module gone, exploit gone.
The xfrm-ESP variant of Dirty Frag bypasses that. Same sink, the page cache write, but it triggers regardless of whether algif_aead is loaded. If you blocklisted algif_aead last week and called it done, you are still exposed to this one.
As one kernel networking developer pointed out on Hacker News, the real sink was never algif_aead itself. It was authencesn performing a 4-byte scratch write at assoclen + cryptlen on a frag the caller still owned. Copy Fail reached that write through AF_ALG. Dirty Frag reaches the same write through plain network sockets. Blacklisting algif_aead closed one door. xfrm-ESP and RxRPC are two more doors to the same room. Until the sink itself is fixed, expect more doors.
The Dirty Frag mitigation in the disclosure itself is to disable the affected modules:
cat > /etc/modprobe.d/dirtyfrag.conf <<'EOF'
install esp4 /bin/false
install esp6 /bin/false
install rxrpc /bin/false
EOF
rmmod esp4 esp6 rxrpc 2>/dev/null
echo 3 > /proc/sys/vm/drop_caches
The drop_caches flush at the end evicts any page-cache modifications already planted. If a system has executed untrusted code since the disclosure, reboot after running this rather than trust the flush alone.
The cost is real this time. Disabling esp4 and esp6 breaks IPsec VPNs. Disabling rxrpc breaks AFS distributed filesystems. For a lot of fleets that is not a meaningful constraint, but for anyone running an actual IPsec gateway it is a choice between privilege escalation exposure and a service outage. There is no equivalent to the AF_ALG “nobody really uses this” escape hatch.
If you do need IPsec to keep working, Red Hat’s advisory points to an alternative: set user.max_user_namespaces=0, which blocks the ESP variant by removing the unprivileged user’s ability to register the XFRM state, while leaving root-managed IPsec alone. It is narrower than disabling the module and worth knowing about.
On Ubuntu, AppArmor’s apparmor_restrict_unprivileged_userns accomplishes the same thing for the ESP variant. It blocks the namespace path. It does not block RxRPC, which never needed namespace privilege in the first place. If your defense is namespace restriction alone, ESP is covered and RxRPC is wide open.
The disclosure timeline
This is where the story gets uncomfortable.
Copy Fail at least had the “researcher published, distributions hadn’t gotten advance notice” failure mode. Dirty Frag has a different one: the patch went public before the disclosure did.
Per an oss-security follow-up, the kernel fix landed on the netdev mailing list as commit f4c50a4034e62ab75f1d5cdd191dd5f9c77fdff4 on May 5. Brad Spengler publicly identified the commit as belonging to the “copyfail-class”. After that, the rest was n-day weaponization, in the words of the researcher who built the public exploit: “The work is n-day weaponization from a public upstream commit, which is standard practice once a security-relevant fix lands in a public tree.”
By the time Kim’s coordinated disclosure email reached linux-distros, a working exploit was already public. Kim then accelerated public disclosure, stating in the oss-security post that “Because the embargo has currently been broken, no patch or CVE exists.” CVEs were assigned later.
I wrote about the same structural problem with Copy Fail, with a twist. Copy Fail’s lesson was that the kernel project has no automatic distribution notification, so a researcher published with the fix already in mainline and the changelog said nothing about exploitability. Dirty Frag’s lesson is that even with a researcher trying to coordinate, the public patch is itself the disclosure. Anyone watching netdev with the right pattern recognition is in the n-day window. I mean, two of these in eight days is a lot to absorb.
Who is actually exposed
Wiz puts it bluntly: any Linux host where an unprivileged user can get a shell. Multi-tenant systems, CI runners, container build farms, shared-kernel container hosts. xfrm registration requires CAP_NET_ADMIN, which means default Docker container configurations filter the capability, and rootless Podman with user namespaces is similarly out of reach. That helps. It does not help if your runtime grants extra capabilities, if you run privileged containers, or if you have any local foothold on the host itself.
Workloads with their own kernel are a different story. Firecracker microVMs and gVisor sandboxes do not share the host kernel page cache, so the exploit has nothing the workload would later read. If your multi-tenant story is per-workload kernels, this one does not change your exposure.
Tested distributions in the disclosure include Ubuntu 24.04.4, RHEL 10.1, openSUSE Tumbleweed, CentOS Stream 10, AlmaLinux 10, and Fedora 44. Red Hat confirms RHEL 8, 9, and 10, plus OpenShift 4, are affected. The xfrm-ESP variant has been vulnerable since January 2017 (commit cac2661c53f3). RxRPC since June 2023 (commit 2dc334f1a63a). The mainline patch for the xfrm-ESP side is f4c50a4034e6. RxRPC, at the time of this writing, does not have a published patch. CISA added Copy Fail to its Known Exploited Vulnerabilities catalog on May 1. I would not bet against Dirty Frag landing there too.
The pattern
Two things are happening at once.
The first is that the page-cache write class is now well-trodden. Dirty Cow in 2016, Dirty Pipe in 2022, Copy Fail and Dirty Frag in 2026. Same architectural sink, different feature path each time. A researcher who finds one finds others. The xfrm-ESP variant exists specifically because Kim saw Copy Fail and looked for adjacent triggers of the same primitive. That intuition is not going to stop being productive.
The second is that the gap between “patch is public” and “every fleet is patched” is the operational reality. For Copy Fail we leaned on AF_ALG being unused. For Dirty Frag we do not have that. Disable the modules and accept the IPsec or AFS cost, set user.max_user_namespaces=0 and accept the user-namespace cost, or update the kernel and reboot. Pick one.
For shared-kernel infrastructure, anything where multiple tenants or untrusted users coexist with the same kernel, every page-cache LPE in this family is a cross-tenant incident waiting on patch latency. That is a property of the architecture. It is why we run our own hardware and patch on our own clock.
Patch your kernels. Block the modules if you can wear the cost. Watch this space, because Dirty Frag will not be the last one.
Eight days. That’s how long it took.
Eight days ago I told you about a vulnerability in the Linux kernel called Copy Fail. That story ended with a fix. The fix arrives, you patch your kernels, the service desk has been redesigned. Done.
Today I’m telling you the same story again. Different door. Same room.
If you didn’t catch the last one, here’s the picture you need.
Picture a law firm. A big one. Hundreds of employees, several floors. There’s a service desk on the ground floor where formal verification work happens. Employees bring documents to be certified, identities to be confirmed. That’s the Linux kernel’s cryptography subsystem - a shared facility every program on your computer can talk to.
There’s an archive room, locked. That’s where the firm’s most sensitive records live - the documents that define who is allowed to do what. In kernel terms, that’s the operating system’s working memory - where it holds the protected files that decide who runs as administrator.
And there’s a work surface at the service desk. A shared table. Specialists lay out archive documents on the table while they process requests. That table sits between the public counter and the archive door.
The Copy Fail story was: an employee submits the right paperwork at the service desk, and the specialists end up writing on the original archive document instead of a copy. Marks land on records they were never authorized to touch.
The fix that shipped told you to close the public counter. Block the one specific intake form most employees would use to walk up. That form was added in 2015, almost nobody actually needed it, and blocking it stopped the attack cold.
Easy fix. Done.
Except it turns out that wasn’t the only door.
Two doors, same room
This new vulnerability is called Dirty Frag. Two CVEs, assigned the day after public disclosure. Same archive room. Same work surface. Two completely different doors to the same room.
The first door is IPsec. In real terms, IPsec is the kernel’s built-in encryption for network traffic - secure tunnels between servers, the kind a corporate VPN uses. The encryption work happens at the same service desk that processed the original Copy Fail requests. Different intake form, same desk, same shared table.
The second door is something called distributed file authentication. In real terms, it’s a feature for sharing files securely across a network of machines - rare in modern fleets but still loaded by default in many distributions. It also routes through the same desk.
Both doors hit the same flaw. The flaw that’s actually in the work surface itself. As one kernel networking developer pointed out on Hacker News, the original Copy Fail mitigation - blocking one intake form - doesn’t matter for either of these.
The form was never the problem. It was always the work surface.
The Copy Fail mitigation does not save you from this one.
The disclosure broke
And here’s where it gets uncomfortable.
Researchers run on something called a coordinated disclosure timeline. Find a bug. Tell the affected vendors privately. Give them time to ship a fix. Publish on a coordinated date, so the world hears about it the same time the patch is available. That’s the deal.
For Dirty Frag, the deal broke. The patch hit the public kernel networking mailing list two days before the researcher’s announcement. Just the patch. No advisory, no CVE, no explanation. But anyone watching that list with the right pattern recognition could see it for what it was. A senior security researcher publicly identified it as a Copy Fail variant within hours.
By the time the original researcher’s coordinated disclosure email reached the major Linux distributions, a working exploit was already public. The researcher accelerated the announcement and noted, in the disclosure post, that because the embargo had been broken, no patch or CVE existed yet. The CVEs got assigned later and so did the patch references.
Dirty Frag was publicly disclosed on May 7th, 2026. The patch had been visible since May 5th.
I mean. Two of these in eight days is a lot to absorb.
What you actually do
The service desk hasn’t been fully redesigned this time. The IPsec door has a patch. The distributed file-system door, at the time of this writing, doesn’t.
You have three options, and they all have a cost.
Option one: Lock both doors. Tell the kernel to refuse to load the IPsec module and the distributed file authentication module, force-remove them if they’re already loaded, and flush the page cache so any modifications already planted get evicted. The cost is real this time. The IPsec module is what lets a Linux box do encrypted VPN tunnels - if you’re running an actual IPsec gateway, locking that door breaks it. The distributed file authentication module powers a system called AFS, rare today but real in some environments. There’s no “nobody really uses this” escape hatch this time. You’re choosing between privilege escalation exposure and a service outage.
Option two: Close the namespace path. If you need IPsec to keep working, Red Hat’s advisory points to a different path. There’s a kernel setting that switches off unprivileged user namespaces. Set it to zero, and ordinary programs lose the ability to register the request that triggers the IPsec door. Root-managed IPsec keeps working. It’s narrower than locking the whole module, and worth knowing about. Ubuntu users get an equivalent through AppArmor. Either one closes the IPsec door but leaves the distributed file-system door open, because that one never needed namespace privilege in the first place.
Option three: Update the kernel and reboot. That’s the actual fix. Ubuntu, Red Hat, SUSE, Debian - all of them are pushing the patch right now.
CISA, that’s America’s cyber defence agency, added Copy Fail to its known exploited vulnerabilities list a week ago. I wouldn’t bet against Dirty Frag landing there too.
Who is actually exposed
Anywhere an unprivileged user can get a shell on a Linux host. Multi-tenant systems. CI runners. Container build farms. Any place where multiple people share a kernel.
Default container configurations strip the capability the IPsec door needs, so a stock Docker container or a rootless Podman container is mostly out of reach. It doesn’t help if your runtime grants extra capabilities, if you run privileged containers, or if you have any local foothold on the actual host.
Per-workload kernels - Firecracker microVMs, gVisor sandboxes - don’t share a service desk between tenants. Each workload runs on its own kernel. If your multi-tenant story is per-workload kernels, this one doesn’t change your exposure.
The pattern
Dirty Cow in 2016. Dirty Pipe in 2022. Copy Fail eight days ago. Dirty Frag today. Four vulnerabilities, ten years, same architectural shape. A controlled write into memory that was supposed to be protected. Different routes into the archive, via different shared work surfaces.
A researcher who finds one finds others. Copy Fail was found because someone built an automated scan and pointed it at the right part of the kernel. Dirty Frag was found because someone read the Copy Fail disclosure and looked for adjacent doors. That intuition isn’t going to stop being productive.
The first thing happening here is that this bug class is well-trodden. Researchers know where to look. So do the tools. Every page-cache write vulnerability in this family is going to surface faster than the one before it.
The second thing is that the gap between the patch being public and every fleet being patched is the operational reality. For Copy Fail we leaned on the public counter being unused. For Dirty Frag we don’t have that. Disable the modules and accept the IPsec or AFS cost. Close the namespace path and accept the namespace cost. Or update the kernel and reboot. Pick one.
For shared-kernel infrastructure - anything where multiple tenants or untrusted users coexist on one kernel - every page-cache vulnerability in this family is a cross-tenant incident waiting on patch latency. That’s not a criticism of any specific cloud provider. It’s a property of the architecture.
It’s why we run our own hardware, and patch on our own clock.
The IPsec door has a fix. The other one is coming. Patch your kernels.
I’m Hany Fahim.