Dirty Frag and the Copy-Fail Lineage: Why AI Will Find the Next One First

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:

VulnYearSubsystemRoot CauseHidden For
Dirty COW2016mm/gup.cRace in COW page fault handler9 years
Dirty Pipe2022pipe/spliceStale PIPE_BUF_FLAG_CAN_MERGE2 years
Copy Fail2026(CVE-2026-31431)Same class, details pendingTBD
Dirty Frag2026xfrm/ESP-in-UDPMSG_SPLICE_PAGES no-COW fast pathTBD

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:

  1. Trigger module auto-load via the XFRM user netlink interface (no privileges needed — the kernel helpfully loads esp4/esp6 for you)
  2. Reach the no-COW splice path from userspace
  3. Write into page-cache pages backing read-only files
  4. 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

AI compresses the discovery timeline by finding variants of known bug patterns across the entire codebase simultaneously.
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/esp6 modules 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_PAGES usage — 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

Thread

0
⌘/Ctrl+Enter to sendType / for commands · Tab to @mention