News

Security researchers have disclosed a fresh, unpatched local privilege escalation (LPE) vulnerability affecting the Linux kernel. Nicknamed “Dirty Frag,” the issue builds on the same class of page-cache corruption bugs as recent flaws like Copy Fail (CVE-2026-31431, CVSS 7.8) and has been reported to kernel maintainers on April 30, 2026.

Researcher Hyunwoo Kim (@v4bel) described Dirty Frag as a technique that attains root privileges across most Linux distributions by linking two distinct page-cache write vulnerabilities: xfrm-ESP Page-Cache Write and RxRPC Page-Cache Write. According to Kim, Dirty Frag extends the family of logic bugs that includes Dirty Pipe and Copy Fail. It is deterministic – it does not rely on timing or racing conditions – and fails cleanly (without triggering kernel panics), which yields a very high success rate for exploitation.

At the time of reporting no CVE has been assigned specifically to Dirty Frag; public disclosure of detailed analysis and an exploit for the xfrm-ESP Page-Cache Write by a third party reportedly broke the embargo. That public release accelerated awareness and defensive guidance before an official CVE could be issued.

If weaponized, the exploit chain allows an unprivileged local user to elevate to root on a broad set of Linux releases, including Ubuntu 24.04.4, RHEL 10.1, openSUSE Tumbleweed, CentOS Stream 10, AlmaLinux 10, and Fedora 44.

Kim traced the origins of the two underlying bugs: the xfrm-ESP Page-Cache Write issue stems from a source-code commit made in January 2017, while the RxRPC Page-Cache Write flaw was introduced in June 2023. Notably, the January 17, 2017 commit is also linked to a separate buffer overflow tracked as CVE-2022-27666 (CVSS 7.8) that impacted several distributions.

The xfrm-ESP Page-Cache Write vulnerability resides in the IPSec (xfrm) subsystem and provides a small, deterministic store primitive – similar to Copy Fail – that overwrites a few bytes in kernel page-cache regions. Triggering it requires creating a user namespace, a capability that Ubuntu commonly prevents when AppArmor is active, which blocks this path on some installations.

The RxRPC Page-Cache Write variant, on the other hand, does not depend on the ability to create user namespaces. However, the rxrpc.ko kernel module is not present in many distributions’ default builds. For instance, RHEL 10.1’s default configuration does not ship rxrpc.ko, whereas Ubuntu typically loads that module by default, making the RxRPC path viable there.

Kim explains that chaining the two flaws covers environments where one technique is blocked: if user namespaces can be made, the xfrm/ESP exploit executes first; when namespace creation is prevented but rxrpc.ko is available (as on Ubuntu), the RxRPC exploit can be used instead.

Vendor and distribution advisories add technical color to the bug. CloudLinx described the vulnerability as reachable through the XFRM user netlink interface and related to the “ESP-in-UDP MSG_SPLICE_PAGES no-COW fast path.” AlmaLinux noted that the issue lives in in-place decryption fast paths for esp4, esp6 and rxrpc: when a socket buffer carries paged fragments that the kernel does not privately own (for example, pipe pages attached via splice(2)/sendfile(2)/MSG_SPLICE_PAGES), the receive path may decrypt directly over those externally backed pages, thereby exposing or corrupting plaintext that an unprivileged process still references.

The situation is made more urgent by the publication of a working proof-of-concept (PoC) capable of elevating privileges to root with a single command. Until official patches are available, administrators are advised to prevent the vulnerable modules from loading by creating a modprobe blacklist and unloading any instances already present. One recommended command to implement this temporary mitigation is:

sudo sh -c "printf 'install esp4 /bin/falseninstall esp6 /bin/falseninstall rxrpc /bin/falsen' > /etc/modprobe.d/dirtyfrag.conf; rmmod esp4 esp6 rxrpc 2>/dev/null; true"

It is important to note that Dirty Frag operates regardless of whether the kernel’s algif_aead module is enabled. That means systems where the known Copy Fail countermeasure (blacklisting algif_aead) has been applied remain susceptible to Dirty Frag.

“Dirty Frag can be triggered regardless of whether the algif_aead module is available,” Kim warned, underscoring that the Copy Fail mitigation is insufficient to block this new chain.

Researchers and vendors are coordinating fixes, and users should watch for official kernel updates from their distribution vendors. In the meantime, applying the temporary module blacklist and minimizing local untrusted access remain practical steps to reduce exposure.