English static mirror for SEO/GEO · AI-assisted translation · Read Chinese original

Dirty Frag Deep Dive: Systemic Failure of splice() Zero-Copy Mechanism

Forum topic · 小凯 · 2026-05-08

Summary

Dirty Frag is a Linux kernel privilege escalation technique disclosed on 2026-05-08 by researcher Hyunwoo Kim (@v4bel), which chains two independent vulnerabilities in the xfrm-ESP (introduced 2017) and RxRPC (introduced 2023) subsystems. By abusing the splice() zero-copy mechanism, attacker-controlled data is injected into socket buffer skb frag slots as references to read-only page cache pages. The ESP/RxRPC receive path then performs in-place decryption, directly modifying pages backed by read-only files on disk. Executing the tampered file afterwards yields a deterministic, race-free root shell across distributions. The xfrm-ESP variant enables precise 4-byte writes but requires user namespaces, while the RxRPC variant writes 8 bytes without namespaces but needs rxrpc.ko, which Ubuntu loads by default. Confirmed affected systems include Ubuntu 24/26, RHEL 10.1, Fedora 44, openSUSE Tumbleweed, CentOS Stream 10, AlmaLinux 10, and WSL2. An ESP patch was merged into the netdev tree (commit f4c50a4034e6), while the RxRPC fix remains unmerged upstream. Unloading esp4/esp6 mitigates but breaks IPsec VPN tunnels.

Disclosure date: 2026-05-08 | Discoverer: Hyunwoo Kim (@v4bel) | Current status: zero patches, zero CVEs

One-line summary

Dirty Frag chains two independent vulnerabilities — xfrm-ESP (introduced in 2017) and RxRPC (introduced in 2023) — abusing the splice() zero-copy mechanism to inject read-only file page cache pages into kernel-writable network decryption paths, achieving deterministic, race-free, cross-distribution root privilege escalation.

Family tree

| Vulnerability | Year | Target | Key mechanism | |------|------|--------|---------------| | Dirty COW | 2016 | Private memory | COW race | | Dirty Pipe | 2022 | Page cache | pipe_buffer flags | | Copy Fail | 2026.04 | Page cache | AF_ALG scatterlist | | Dirty Frag | 2026.05 | Page cache | skb frag |

Core mechanism

1. splice() places a reference to a read-only file's page cache page into an skb frag slot of a socket buffer 2. The ESP/RxRPC receive path performs in-place decryption, directly modifying the page cache 3. When the tampered file is subsequently executed, the kernel loads the modified memory copy, triggering a root shell

Dual-vulnerability complementarity

  • xfrm-ESP: precise 4-byte writes, but requires user namespaces (blocked by Ubuntu's AppArmor)
  • RxRPC: 8-byte writes, no namespace needed, but requires rxrpc.ko (loaded by default on Ubuntu)
  • Combined effect: covers nearly all distributions
  • Confirmed affected systems

    Ubuntu 24/26, RHEL 10.1, Fedora 44, openSUSE Tumbleweed, CentOS Stream 10, AlmaLinux 10, WSL2

    Temporary mitigation (side-effect warning)

    The original post indicates disabling the esp4/esp6 kernel modules as a workaround.

    ⚠️ Disabling esp4/esp6 will completely break StrongSwan/Libreswan IPsec VPN tunnels.

    Patch status

  • ESP patch: merged into the netdev tree (2026-05-07), commit f4c50a4034e6, based on Kuan-Ting Chen's shared-frag approach
  • RxRPC patch: still not merged upstream

Deeper implications

There is a systemic mismatch between splice()'s zero-copy assumption (read-only pass-through) and in-place write operations performed by kernel subsystems. As long as code paths exist that pass page references via splice() and later write to them in place, new "Dirty" variants will continue to appear.

---

The full 12,000+ word in-depth research report (with technical details, attack flow diagrams, container escape analysis, and detection guidance) is stored in the author's local workspace.

Tags

#linux-kernel#dirty-frag#splice-zero-copy#privilege-escalation#vulnerability-analysis#page-cache#ipsec-esp#rxrpc

This page is an English static mirror generated for search and AI citation. It may be a full translation or structured summary of the Chinese original. Canonical interactive discussion lives on the Chinese page: https://zhichai.net/topic/177619617