Dirty Frag and the Copy-Fail Lineage: Why AI Will Find the Next One First
From Dirty COW to Dirty Frag — Linux keeps betting on no-COW fast paths and losing. Here's why AI variant analysis changes the timeline. 🔬
On this page
Yesterday a researcher dropped a one-liner that roots any unpatched Linux box. No special permissions. No complex setup. Just a Bash script, a small C payload, and a decade-old design pattern the kernel team keeps accidentally repeating.
The bug is called Dirty Frag. It’s the newest member of a family I’m calling the “copy-fail lineage” — kernel vulnerabilities that exploit shortcuts in Linux’s copy-on-write machinery. And if you squint at the pattern, you’ll see exactly why AI-powered variant analysis is about to eat this entire bug class alive.
The Copy-Fail Family Tree
Linux’s memory subsystem makes a promise: when you fork a process or read a file, the kernel shares physical pages and only copies them when someone writes. That’s copy-on-write. It’s elegant, it’s fast, and every time the kernel adds a “fast path” that skips the copy step for performance, someone eventually finds a way to write through it from unprivileged context.
Here’s the lineage:
| Vuln | Year | Subsystem | Root Cause | Hidden For |
|---|---|---|---|---|
| Dirty COW | 2016 | mm/gup.c | Race in COW page fault handler | 9 years |
| Dirty Pipe | 2022 | pipe/splice | Stale PIPE_BUF_FLAG_CAN_MERGE | 2 years |
| Copy Fail | 2026 | (CVE-2026-31431) | Same class, details pending | TBD |
| Dirty Frag | 2026 | xfrm/ESP-in-UDP | MSG_SPLICE_PAGES no-COW fast path | TBD |
Four bugs. Same bet. Same loss. The kernel adds a zero-copy shortcut for performance, assumes it won’t be reachable from unprivileged context, and a researcher proves otherwise.
How Dirty Frag Works
The vulnerability lives in the xfrm subsystem — Linux’s IPsec transformation framework. Specifically, it’s in the ESP-in-UDP path that uses MSG_SPLICE_PAGES to avoid copying packet data.
// The fast path promise: "we won't copy this page, trust us"
// Narrator: they should not have trusted the fast path.
msg.msg_flags |= MSG_SPLICE_PAGES; // no-COW shortcut
The exploit chain:
- Trigger module auto-load via the XFRM user netlink interface (no privileges needed — the kernel helpfully loads
esp4/esp6for you) - Reach the no-COW splice path from userspace
- Write into page-cache pages backing read-only files
- Overwrite a SUID binary in memory — congratulations, you’re root
The nastiest part? Page-cache corruption means the on-disk binary looks untouched. Your integrity checker sees a clean file. The in-memory version is already compromised. It’s forensically invisible unless you explicitly drop caches and re-verify.
# The "oh no" mitigation — blocks IPsec but stops the exploit
echo "blacklist esp4" >> /etc/modprobe.d/dirty-frag.conf
echo "blacklist esp6" >> /etc/modprobe.d/dirty-frag.conf
echo "blacklist rxrpc" >> /etc/modprobe.d/dirty-frag.conf
# Drop page-cache because you can't trust what's loaded
echo 3 > /proc/sys/vm/drop_caches
# Your IPsec tunnels are dead now. You're welcome.
The Discovery Stories
Each bug in this family was found by human intuition — and each story highlights why automated systems missed it.
Dirty COW (2016): Phil Oester found it by spotting exploit traffic in the wild. The bug existed since kernel 2.6.22 (2007). Nine years of code review, static analysis, and fuzzing — nothing caught it. An attacker found it before any defender did.
Dirty Pipe (2022): Max Kellermann spent months chasing corrupted gzip log files. ZIP magic bytes (PK) appearing inside compressed output that shouldn’t contain them. He traced the corruption through the splice syscall to stale pipe buffer flags. A masterpiece of detective work that no fuzzer would’ve reproduced — the trigger required a specific sequence of fill-drain-splice-write operations.
Dirty Frag (2026): Disclosed by Hyunwoo Kim on oss-security, May 7th 2026. Same class as Copy Fail (CVE-2026-31431) but in a different subsystem. Public PoC roots any affected box in a single command.
The pattern: human finds it after years of the bug hiding. Fuzzers miss it because the trigger conditions are semantic, not random.
Enter AI: The Variant Analysis Machine
In October 2024, Google’s Project Zero and DeepMind published Big Sleep — an LLM-based agent that found a real zero-day stack buffer underflow in SQLite. First confirmed case of AI discovering an exploitable vulnerability in widely-deployed software.
The approach: start from a known patch, understand the pattern of the bug, then search for the same pattern elsewhere. Variant analysis — but at machine speed and across millions of lines of code.
Here’s why this matters for the copy-fail lineage:
# What a variant analysis agent "sees" in the copy-fail pattern:
pattern = {
"mechanism": "zero-copy/splice fast path skips COW protection",
"precondition": "page-cache reference shared with userspace",
"trigger": "write path reachable from unprivileged context",
"impact": "arbitrary write to read-only page-cache pages",
}
# Kernel locations with MSG_SPLICE_PAGES or similar no-COW paths:
# Each one is a candidate for the same bug class.
# A human auditor checks maybe 3-5 per quarter.
# An AI agent checks all of them in hours.
Big Sleep’s SQLite finding is the proof of concept. The bug it found evaded 150 CPU-hours of AFL fuzzing because the harness didn’t enable the right extension. Coverage-guided fuzzers can’t find what they can’t reach. An LLM that understands the semantic pattern doesn’t have that blind spot.
Traditional vs AI-Accelerated Vulnerability Discovery
View diagram source
flowchart TD
A[Bug class discovered] -->|Traditional| B[Human audits similar code]
A -->|AI-accelerated| C[LLM agent scans entire codebase]
B -->|Months/years| D[Find 1-2 variants]
C -->|Hours/days| E[Find all reachable variants]
D -->|Next vuln found by attacker| F[Reactive patch]
E -->|Variants fixed pre-disclosure| G[Proactive hardening]
F -->|Slow rollout| H[Exploitation window: weeks]
G -->|Pre-release| I[Exploitation window: zero]
The Arms Race Nobody’s Ready For
The same AI that helps defenders find bugs helps attackers exploit them. The timeline compression works both ways:
Defender advantage (today): Scan your own code pre-release. Google runs Big Sleep against their own products. Dirty Frag could theoretically have been caught by scanning all MSG_SPLICE_PAGES call sites for unprivileged reachability.
Attacker advantage (emerging): Watch patch commits. Feed the diff to an LLM. Generate exploit hypotheses. The window between “patch lands in git” and “exploit available” shrinks from weeks to hours.
The uncomfortable math: Linux kernel has ~30 million lines of code. The xfrm subsystem alone has hundreds of code paths. Every MSG_SPLICE_PAGES, every PIPE_BUF_FLAG_CAN_MERGE, every COW-bypass optimization is a bet that the fast path isn’t reachable from an unprivileged context. Humans can’t audit all of them. AI can.
The question isn’t whether AI will find the next copy-fail variant. It’s whether the finder will be a defender with Big Sleep or an attacker with a custom agent and a zero-day broker on speed dial.
Patch now, think later. If you run any Linux kernel on CloudLinux, RHEL, Debian, or Ubuntu — check your xfrm module exposure immediately. Blacklist esp4/esp6/rxrpc if you don’t use IPsec. Drop page-cache. Wait for the kernel update. The PoC is public and it’s a one-liner.
What to Do Today
Immediate (Dirty Frag):
- Check if
esp4/esp6modules are loaded:lsmod | grep esp - If you don’t need IPsec: blacklist the modules and reboot
- Drop page-cache on any box that’s been exposed:
echo 3 > /proc/sys/vm/drop_caches - Monitor your distro’s security tracker for the patched kernel
Structural (the whole bug class):
- Audit your kernel’s
MSG_SPLICE_PAGESusage — every call site is a potential copy-fail variant - If you maintain kernel modules: never assume a fast path is unreachable from unprivileged context. Prove it. Test it. The history says your assumption is wrong.
- Watch for AI-powered kernel auditing tools. Google’s Big Sleep approach will likely become available to the broader security community within a year.
The kernel team keeps adding zero-copy fast paths for performance. Each one is a bet that the no-COW shortcut won’t be reachable from unprivileged context. Four times now, they’ve lost that bet. The fifth time, an AI agent will probably find it before a human does — and the only question is which side of the fence that agent sits on.
Patch your boxes. Then go read the Big Sleep paper. The future of vulnerability research just walked in, and it doesn’t need coffee breaks.
Sources
- Dirty Frag — CloudLinux mitigation and kernel update — disclosure timeline, affected versions, module blacklist mitigation
- CVE-2016-5195 (Dirty COW) — NVD — CVSS 7.0, race condition in
mm/gup.c, affected kernels 2.6.22–4.8.2 - Dirty COW — dirtycow.ninja — dedicated disclosure site by Phil Oester
- CVE-2022-0847 (Dirty Pipe) — NVD — CVSS 7.8, improper initialization in pipe buffer flags
- Dirty Pipe — Max Kellermann’s technical writeup — full discovery story, root cause analysis, exploit mechanism
- CVE-2024-1086 (nf_tables) — NVD — CVSS 7.8, use-after-free in
nft_verdict_init() - CVE-2024-1086 exploit — Notselwyn — public PoC and writeup
- From Naptime to Big Sleep — Google Project Zero — first AI-discovered zero-day in SQLite, LLM-based variant analysis agent
- Dirty Frag upstream fix — netdev/net.git — kernel patch commit
- CISA Known Exploited Vulnerabilities Catalog — Dirty COW, Dirty Pipe, and nf_tables all listed