Dirty Frag is a new, currently unpatched local privilege escalation vulnerability in the Linux kernel that allows any local user to obtain root rights on most popular distributions (Ubuntu 24.04.4, RHEL 10.1, openSUSE Tumbleweed, CentOS Stream 10, AlmaLinux 10, Fedora 44, and others), while the standard temporary mitigation for Copy Fail (CVE-2026-31431) does not work: a working proof-of-concept has been published, exploitation is performed with a single command, and until patches are released the only practical measure remains blocking the esp4, esp6, and rxrpc modules.

Technical details of Dirty Frag

Researcher Hyunwoo Kim describes Dirty Frag as an evolution of the same class of kernel logic bugs as Dirty Pipe and Copy Fail (CVE-2026-31431, CVSS 7.8). The key feature of this class is a deterministic logic bug without a race:

• no race condition or precise timing is required;
• if exploitation fails, the kernel does not crash (no panic);
• the probability of successful privilege escalation is close to 100% in a suitable configuration.

Dirty Frag is built on the combination of two different page cache write bugs in the kernel: xfrm-ESP Page-Cache Write and RxRPC Page-Cache Write. Both flaws allow incorrect modification of data in the page cache that is still under the control of an unprivileged process. This is a classic exploitation scenario for a vulnerability of the Exploit for Privilege Escalation (T1068) type in the MITRE ATT&CK framework.

xfrm-ESP Page-Cache Write: 4-byte write primitive via IPSec

The first component is a vulnerability in the IPSec (xfrm) subsystem, designated by the researcher as xfrm-ESP Page-Cache Write. The bug:

• appeared after a commit in January 2017;
• correlates with the same change that caused the buffer overflow CVE-2022-27666 (CVSS 7.8), described in the NVD entry for CVE-2022-27666;
• gives the attacker a 4-byte write primitive into the kernel page cache, comparable in power to the primitive used in Copy Fail.

This part of the exploit relies on how ESP works together with the page cache: when processing IPSec traffic (through the XFRM user netlink interface) the kernel performs in-place decryption on top of pages that may be backed by external objects (for example, pipe pages attached via splice() or sendfile()). This makes it possible to write to data for which an unprivileged process still holds a reference.

A critical limitation: exploiting the xfrm-ESP variant requires the ability to create user namespaces. On Ubuntu this is blocked by default by AppArmor profiles, so in such a configuration this exploitation path is not available.

RxRPC Page-Cache Write: bypassing the namespace creation ban

The second component is RxRPC Page-Cache Write. It appeared in the kernel later, after a commit in June 2023, and repeats the same flawed pattern in the decryption path, but:

• does not require permissions to create user namespaces;
• uses the rxrpc.ko module, which is absent in the standard distribution of many distros (for example, RHEL 10.1), but is loaded by default on Ubuntu.

From a technical standpoint, the bug is similar: the RxRPC subsystem, like esp4/esp6, performs in-place decryption on top of pages that are not fully private to the kernel. As a result, plaintext data or kernel structures located on these pages can be corrupted by code from an unprivileged process.

Exploitation chain: mutually covering the “blind spots”

The key engineering insight of Dirty Frag is the combination of two vulnerabilities so that each covers the limitations of the other:

• in environments where user namespace creation is allowed but the rxrpc.ko module is unavailable or not loaded, the xfrm-ESP variant is used;
• in environments like Ubuntu, where AppArmor blocks the creation of user namespaces but rxrpc.ko is enabled by default, the RxRPC variant is exploited.

Thus, for most mass-market distributions there is at least one working exploitation path, and in some configurations there are two. The researcher emphasizes that Dirty Frag can be successfully exploited regardless of whether the algif_aead module is enabled. This means that even systems where Copy Fail is supposedly “closed” by blocking algif_aead remain vulnerable to the new technique.

Threat context and relation to Copy Fail

Copy Fail (CVE-2026-31431), the preceding vulnerability of the same class, is already being actively exploited in real-world attacks, according to the researcher. This is an important indicator: as soon as a public exploit appears for this category of logic bugs in network data processing subsystems, attackers quickly integrate it into their chains — from web shells to container escapes.

Dirty Frag has inherited several unpleasant properties of Copy Fail and Dirty Pipe:

• a local attack vector but with an extremely low entry threshold (ready PoC and one-command execution);
• versatility — the same write primitives can be applied to different targets in memory (binary replacement, modification of /etc/passwd or /etc/shadow, injection into security processes, etc.);
• no noticeable kernel failures on unsuccessful exploitation, which complicates detection based on failure events.

Unlike Copy Fail, the new technique bypasses the main known temporary mitigation — blocking the algif_aead module. This makes all current “quick fixes” for Copy Fail incomplete: infrastructure that relied solely on a denylist for algif_aead gains a false sense of security while retaining the full risk of local root takeover.

Impact assessment for organizations

The environments at greatest risk are those where a potential attacker can obtain any form of local access — both direct interactive access and via exploitation of other application vulnerabilities:

• cloud and hosting providers with multi-tenant Linux servers;
• corporate application servers (web, databases, CI/CD) where compromise of a single service yields low-level local access;
• virtual desktops and terminal servers based on Linux with many unprivileged accounts;
• development and test environments where additional kernel subsystems are often enabled and security policies are less strict.

Potential consequences if no action is taken:

• instant privilege escalation to root after any local foothold (RCE in a web application, a compromised user account, a vulnerable container);
• persistent foothold in the system by modifying system binaries, bootloaders, kernel modules, or configurations;
• disabling or tampering with security controls (EDR agents, audit logs);
• violations of compliance requirements where control over administrative access and system integrity is a key audit element.

A particular concern is that, according to the researcher, a fully working PoC is already available and performs escalation “with a single command.” This sharply reduces the time between disclosure of the vulnerability and its widespread inclusion in exploit kits, including automated ones.

Practical defense recommendations

1. Immediate temporary measures

Until official Linux kernel patches are released, it is recommended to:

• block loading of the esp4, esp6, and rxrpc modules:
  • add the following lines to files in /etc/modprobe.d/:
    • blacklist esp4
    • blacklist esp6
    • blacklist rxrpc
  • if possible, unload already loaded modules: rmmod esp4 esp6 rxrpc (taking into account the risk of service downtime).
• carefully assess the impact on your infrastructure: blocking esp4/esp6 will affect IPSec tunnels, and disabling rxrpc will impact services that use this protocol.

This directly correlates with the recommendation from the AlmaLinux vendor, which describes the defect in the “ESP-in-UDP MSG_SPLICE_PAGES no-COW fast path” and its reachability via the XFRM user netlink interface.

2. Checking exposure

Basic steps to assess risk:

• Identify distributions and versions within the risk zone:
  • confirmed so far: Ubuntu 24.04.4, RHEL 10.1, openSUSE Tumbleweed, CentOS Stream 10, AlmaLinux 10, Fedora 44;
  • other distributions with similar kernel versions may also be vulnerable.
• Check whether the relevant modules are loaded:
  • lsmod | egrep 'esp4|esp6|rxrpc'
  • if needed — modinfo esp4, modinfo rxrpc to confirm the presence of modules on the system.
• Clarify policies for creating user namespaces:
  • on Ubuntu systems — check AppArmor profiles;
  • on servers of other distributions — where possible, restrict creation of user namespaces for unprivileged users.

3. Strengthening monitoring and incident response

Given the availability of a PoC, it makes sense to:

• monitor unexpected loading of the esp4, esp6, and rxrpc modules (via auditd, systemd-journald, kernel monitoring tools);
• track the launch of tools using splice() and sendfile() in combinations unusual for the system, especially from unprivileged accounts;
• strengthen response to any signs of local compromise — from indications of web shells to suspicious binaries in a user’s home directory: in the presence of Dirty Frag, any local access should be treated as potential root acquisition.

4. Preparing for patch deployment

Since kernel developers were notified of the vulnerability on 30 April 2026, updates are expected soon in the branches supported by distributions. It is recommended to proactively:

• plan an out-of-band kernel update with possible reboots of critical nodes;
• prepare a test environment to check the impact of patches on critical services (especially those using IPSec and RxRPC);
• monitor for the appearance of the Copy Fail entry CVE-2026-31431 and related vulnerabilities of the same class in NVD, as well as vendor recommendations from your distributions.

The main takeaway: Dirty Frag opens a universal path to root for any local attacker on most modern Linux distributions, and previously applied temporary measures against Copy Fail no longer provide sufficient protection; prioritize immediate blocking of the esp4, esp6, and rxrpc modules wherever business processes permit, and prepare your infrastructure for rapid deployment of updated kernels as soon as official patches are released.