Another Week, Another Universal Linux LPE
If you skipped patching after Copy Fail in March, congratulations — you're already pwned twice. The same researcher who broke Copy Fail (Hyunwoo Kim, of V4bel fame) just dropped **Dirty Frag** on the oss-security list on May 7, complete with a working public proof-of-concept and exploit code on GitHub. It chains two long-dormant kernel bugs, ignores embargo because the embargo broke first, and yields uid=0 in a single shell command on basically every distro you care about.
If your threat model includes "unprivileged user on the box," your threat model just got worse.
What Dirty Frag Actually Is
Dirty Frag isn't one bug — it's two distinct page-cache write primitives chained together so a regular user can rewrite kernel-controlled memory pages they shouldn't be able to touch:
- **CVE-2026-43284** — `xfrm-ESP` (IPsec). The bug lives in the in-place decryption fast paths of `esp4` and `esp6`. When an `sk_buff` carries paged fragments that aren't privately owned by the kernel, the receive path decrypts directly over those externally-backed pages. An unprivileged process keeps a reference to those same pages via `splice()`/`vmsplice()`, so the kernel ends up writing attacker-controlled plaintext into pages the user still holds. - **CVE-2026-43500** — `rxrpc`/`rxkad`. The RxRPC authentication path has the same shape: in-place decryption over pages that aren't kernel-private, exploitable through `AF_ALG` to grind keys offline and then overwrite cached file content.
The ESP bug was committed in **January 2017**. The RxRPC bug landed in **June 2023**. They've been sitting there for nine and three years respectively, untouched, in code that ships in literally every mainline kernel that distro vendors actually ship.
This is the part that should scare you: Dirty Frag is **deterministic**. No race condition, no flaky window, no kernel panic on failure. It's a logic bug. It works on the first try. Kim's PoC reports near-100% success in their testing.
What It Looks Like When It Pops
There are two exploit paths in the public PoC, depending on what's loaded.
The **ESP path** is the headline one. The exploit:
1. Sets up XFRM (IPsec) security associations with crafted sequence numbers over UDP encapsulation. 2. Triggers in-place ESP decryption, which writes through into a page the attacker has spliced from a target file. 3. Overwrites `/usr/bin/su` with a 192-byte x86_64 ELF that just `execve`s `/bin/sh`. 4. Calls `su`. You're root.
The **rxrpc path** is the fallback for systems that have ESP modules disabled. It uses `rxkad` token verification to decrypt file bytes in place, brute-forces a key offline through `AF_ALG`, and rewrites `/etc/passwd` to give the root entry an empty password — then logs in via PAM with `nullok`. Slower, but if you've blocklisted ESP and left rxrpc loaded, it still wins.
No SMEP/SMAP bypass. No KASLR leak. No ROP gadget hunting. Just legitimate kernel APIs being misused into giving you a write primitive against pages you shouldn't be allowed to write.
Distros Confirmed Vulnerable
Kim tested Dirty Frag on a depressingly comprehensive list:
- Ubuntu 24.04.4 (HWE kernel, 6.11.x branch) - RHEL 10.1 (5.14.x backport tree — yes, the one Red Hat keeps insisting is fine) - openSUSE Tumbleweed (rolling, 6.18.x at time of testing) - CentOS Stream 10 - AlmaLinux 10 - Fedora 44 (the one that just shipped with kernel 6.19)
If your distro isn't on that list it's not because you're safe. It's because Kim didn't bother testing it. The bugs are in mainline. If you're running anything between 4.10 and 7.0.4, you have CVE-2026-43284. If you're running anything from 6.4 onward, you also have CVE-2026-43500. Arch is vulnerable. Debian is vulnerable. NixOS is vulnerable. Your homelab Proxmox box is vulnerable.
I use Arch, btw. I also `rmmod`'d esp4 esp6 rxrpc about ten minutes after reading the disclosure, and you should too.
The Patch Situation Is Annoying
Greg KH cut **7.0.5, 6.18.28, 6.12.87, and 6.6.138** stable kernels on May 8 with a partial fix. Read that carefully: **partial**. The ESP half (CVE-2026-43284) merged into the upstream netdev tree on May 7. The RxRPC half (CVE-2026-43500) is still in development, hasn't been merged anywhere, and the Phoronix-following crowd reports the patch is being rewritten because the first attempt regressed AFS performance by ~12%.
So if you `apt upgrade` today, you're closing the front door but the side door is still wide open. The rxrpc fallback path in the PoC absolutely still works against patched stable kernels.
Mitigation that actually works right now:
``` echo 'install esp4 /bin/true' | sudo tee /etc/modprobe.d/dirtyfrag.conf echo 'install esp6 /bin/true' | sudo tee -a /etc/modprobe.d/dirtyfrag.conf echo 'install rxrpc /bin/true' | sudo tee -a /etc/modprobe.d/dirtyfrag.conf sudo rmmod rxrpc esp6 esp4 2>/dev/null ```
If you're not actively using IPsec or AFS — and let's be honest, on a desktop or a typical container host you are not — there is zero reason these modules need to be loadable. Kill them.
Why This Keeps Happening
I'm going to say the unpopular thing: this is what happens when you let in-place crypto operations run over `sk_buff` pages without auditing who actually owns those pages. The pattern that produced both halves of Dirty Frag is the same pattern that produced Copy Fail in March, and the same pattern Jann Horn flagged on the kernel security list back in 2021 when nobody listened. It is the same pattern as Dirty Pipe (CVE-2022-0847) — page-cache writes through a primitive that was never meant to write through.
The maintainers know. The structure of the receive paths is the problem. Nothing about the patches landing this week fixes the **class** of bug — they fix two specific instances. There will be a third. There will be a fourth. Bet on it.
What To Do Right Now
1. Blocklist the modules above on every Linux box you administer. Do it today. 2. Update to **7.0.5 / 6.18.28 / 6.12.87 / 6.6.138** as soon as your distro ships them, but understand you're still exposed via rxrpc until that second patch lands. 3. If you run multi-tenant containers, audit your seccomp profiles for `socket(AF_KEY, ...)`, `socket(AF_RXRPC, ...)`, and `splice`/`vmsplice` and consider whether your tenants need them. They almost certainly don't. 4. Stop autoloading network protocol modules on demand. `modprobe.d` blocklists are free.
The year of the Linux desktop already happened. The year of "finally treating the kernel attack surface seriously" still hasn't. Patch your boxes.
Loading comments...