"Dirty Frag is a vulnerability (class) that achieves root privileges on most Linux distributions by chaining the xfrm-ESP Page-Cache Write vulnerability and the RxRPC Page-Cache Write vulnerability," security researcher Hyunwoo Kim (@v4bel) wrote, summing up a new, unpatched local privilege escalation that arrived in the Linux kernel codebase years apart and now can be chained to yield root.
Hyunwoo Kim's technical summary and timeline
Kim reported the vulnerability to Linux kernel maintainers on April 30, 2026, and described Dirty Frag as an extension of the "Dirty Pipe" and "Copy Fail" bug classes. Unlike some prior exploits that rely on race conditions, Kim says Dirty Frag is "a deterministic logic bug that does not depend on a timing window," meaning it requires no race, does not cause kernel panic on failure, and offers "a very high" success rate when successful.
Kim also traced the two underlying defects to distinct commits: the xfrm-ESP Page-Cache Write was introduced in a January 2017 commit, while the RxRPC Page-Cache Write was introduced in June 2023. The January 17, 2017 commit was previously implicated in another buffer overflow, CVE-2022-27666 (CVSS score: 7.8), according to Kim's write-up.
xfrm-ESP Page-Cache Write and RxRPC Page-Cache Write
The exploit works by chaining two page-cache write primitives. xfrm-ESP Page-Cache Write, rooted in the IPSec (xfrm) subsystem, provides attackers with a 4-byte store primitive and can overwrite a small amount in the kernel's page cache—an effect similar to Copy Fail (CVE-2026-31431, CVSS score: 7.8). That primitive, however, normally requires an unprivileged user to create a namespace, a capability blocked by Ubuntu via AppArmor.
RxRPC Page-Cache Write, on the other hand, "does not require the privilege to create a namespace," Kim noted, but the rxrpc.ko module is not included in many distributions by default. Kim highlighted that RHEL 10.1's default build does not ship rxrpc.ko, while on Ubuntu the rxrpc.ko module is loaded by default—allowing the RxRPC primitive to operate where namespace creation is blocked.
Which distributions and configurations are affected
According to the researcher, successful exploitation can yield elevated root access on "most Linux distributions," and the advisory lists specific builds by name: Ubuntu 24.04.4, RHEL 10.1, openSUSE Tumbleweed, CentOS Stream 10, AlmaLinux 10, and Fedora 44. Kim emphasized that Dirty Frag can be triggered "regardless of whether the algif_aead module is available," so systems that applied the publicly known Copy Fail mitigation (algif_aead blacklist) remain vulnerable to Dirty Frag.
CloudLinx and AlmaLinux technical advisories
CloudLinx described the flaw as residing in the "ESP-in-UDP MSG_SPLICE_PAGES no-COW fast path and is reachable via the XFRM user netlink interface." AlmaLinux added detail about the mechanism: "The bug lives in the in-place decryption fast paths of esp4, esp6, and rxrpc: when a socket buffer carries paged fragments that are not privately owned by the kernel (e.g., pipe pages attached via splice(2)/sendfile(2)/MSG_SPLICE_PAGES), the receive path decrypts directly over those externally-backed pages, exposing or corrupting plaintext that an unprivileged process still holds a reference to."
Mitigation, PoC release, and immediate steps
Adding to the urgency, a working proof-of-concept (PoC) that can be exploited to gain root with a single command has been published. Until official patches are available, the source advises blocklisting the kernel modules esp4, esp6, and rxrpc so they cannot be loaded. The recommended one-line measure is presented verbatim:
sudo sh -c "printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/dirtyfrag.conf; rmmod esp4 esp6 rxrpc 2>/dev/null; true"
The researcher framed the chaining rationale succinctly: "Chaining the two variants makes the blind spots cover each other. In an environment where user namespace creation is allowed, the ESP exploit runs first. Conversely, on Ubuntu, where user namespace creation is blocked but rxrpc.ko is built, the RxRPC exploit works."
What this means for Ubuntu, RHEL, and security teams
- Ubuntu administrators: AppArmor blocking of user namespace creation can prevent the xfrm-ESP primitive, but Ubuntu's default loading of rxrpc.ko leaves systems open to the RxRPC primitive unless the module is blocklisted.
- RHEL administrators: The default RHEL 10.1 build does not ship rxrpc.ko, reducing exposure to the RxRPC primitive, but systems remain at risk where xfrm/ESP is present and user namespaces are permitted.
- Security operations teams: Existing Copy Fail mitigations (algif_aead blacklist) do not prevent Dirty Frag, and the published PoC increases the urgency of applying the module blocklist or other mitigations until kernel patches are released.
Dirty Frag joins a lineage of page-cache write primitives that have repeatedly yielded local root exploits. The underlying defects stem from code paths introduced in different years and in different subsystems, and their combination has produced an exploit chain that can bypass some prior mitigations. For now, the defensive path is clear in the record: block the esp4, esp6, and rxrpc modules, monitor vendor advisories for patches, and assume exposure if those modules are present or if user namespace creation is permitted.
Original reporting: https://thehackernews.com/2026/05/linux-kernel-dirty-frag-lpe-exploit.html
