Less than two weeks after the public disclosure of the Copy Fail vulnerability (CVE-2026-31431), another local privilege escalation (LPE) vulnerability in the Linux kernel has been revealed. Referred to as "Dirty Frag," this vulnerability was discovered and reported by Hyunwoo Kim (@v4bel) [1]. In this diary, I will provide a brief background on Dirty Frag, and discuss its relationship to Copy Fail. I will then discuss how to mitigate Dirty Frag and outline recommended next steps for system owners.

The existence of Dirty Frag was revealed after the coordinated disclosure embargo was broken by an unrelated third party [1]. Just like Copy Fail [2], Dirty Frag allows an unprivileged local user to escalate to root on most major Linux distributions. Due to the premature disclosure of Dirty Frag, no CVE IDs were assigned [3].

Dirty Frag chains two distinct vulnerabilities:

1. xfrm-ESP Page-Cache Write - residing in the IPsec ESP decryption fast paths (esp4, esp6)
2. RxRPC Page-Cache Write - residing in the RxRPC module

Both sub-vulnerabilities share a common root cause: on a zero-copy send path where splice() plants a reference to a page cache page that an attacker only has read access to into the frag slot of the sender-side skb, the receiver-side kernel code performs in-place crypto on top of that frag. As a result, the page cache of files that an unprivileged user only has read access to (such as /etc/passwd or /usr/bin/su) is modified in RAM, and every subsequent read sees the modified copy [1].

While both Dirty Frag and Copy Fail belong to the same broad vulnerability class (page-cache corruption via kernel crypto in-place operations), they were discovered by different researchers and reside in different kernel subsystems. Copy Fail (CVE-2026-31431) was discovered by researchers at Theori and abuses the algif_aead module in the AF_ALG crypto interface. Dirty Frag, on the other hand, exploits the ESP and RxRPC in-place decryption fast paths directly.

With reference to Table 1, the key differences of each vulnerability are shown.

An interesting factor of Dirty Frag is that chaining the two sub-vulnerabilities covers each other's blind spots. As described in the write-up, neither the xfrm-ESP Page-Cache Write nor the RxRPC Page-Cache Write alone provides a sufficiently reliable primitive for full root escalation. However, when combined, the chained exploit achieves immediate root on most distributions.

The Dirty Frag vulnerability is significant (beyond its possible utility in Capture-the-Flag challenges). Firstly, the vulnerability affects many major Linux distributions with kernels dating back to approximately 2017, similar to Copy Fail. Secondly, due to the unfortunate embargo breach, the working exploit code is publicly available. Thirdly, since no CVE identifier was assigned, any automated workflow or systems tracking vulnerabilities by CVE identifers would not be able to show Dirty Frag automatically. Finally, in the case of containerized environments, an adversary may be able to leverage Dirty Frag, override relevant binaries in the base layer and escape to host.

Currently, patched kernels and live patches are in active build and testing for several distributions [4, 5]. Until a patched kernel or live patch is installed, the following mitigations could be applied:

1. Denylist and unload vulnerable kernel modules

This is the most immediate mitigation available. The vulnerable modules (esp4, esp6, rxrpc) can be denylisted to prevent them from being loaded:

# Unload modules if currently loaded
modprobe -r esp4 esp6 rxrpc

# Denylist modules to prevent loading on boot
echo "Denylist esp4" >> /etc/modprobe.d/dirtyfrag-mitigation.conf
echo "Denylist esp6" >> /etc/modprobe.d/dirtyfrag-mitigation.conf
echo "Denylist rxrpc" >> /etc/modprobe.d/dirtyfrag-mitigation.conf

Important caveat: Denylisting esp4 and esp6 will disable IPsec ESP functionality. If your environment relies on IPsec VPN tunnels or IPsec-encrypted communication, this mitigation will cause disruption. Similarly, unloading rxrpc will affect services that depend on RxRPC (such as AFS filesystems). System administrators should assess the impact before applying this mitigation.

2. Apply live patches where available

CloudLinux KernelCare live patches are being made available for affected CloudLinux versions [4]. This allows patching without rebooting, which may be preferable for production environments where downtime windows are limited.

3. Install patched kernels from testing repositories

AlmaLinux has published patched kernels in their testing repository [5]. Once stable kernels are released for your distribution, apply them promptly and reboot.

4. Revert denylists after patching

After a patched kernel is installed and the system has been rebooted, the denylists can be removed:

rm /etc/modprobe.d/dirtyfrag-mitigation.conf

Dirty Frag joins a growing list of universal Linux LPE vulnerabilities that exploit kernel page-cache handling or memory management primitives. Notable related vulnerabilities include:

• Dirty COW (CVE-2016-5195): Exploited a race condition in copy-on-write memory handling to modify read-only file mappings
• Dirty Pipe (CVE-2022-0847): Exploited uninitialized flags in pipe_buffer to overwrite page cache pages of read-only files
• Copy Fail (CVE-2026-31431): Exploited AF_ALG crypto interface to write controlled bytes into page cache

It appears that kernel optimizations which perform in-place operations on shared page-cache-backed pages without verifying exclusive ownership introduce exploitable primitives (the ability to corrupt the global page cache by tricking the kernel into treating a shared/read-only page as a private, writable buffer). This suggests that closer attention to zero-copy and in-place operation paths in the kernel are required.

As Dirty Frag does not have a CVE ID yet, defenders have to rely on distribution advisories and direct monitoring of security mailing lists rather than automated CVE-based alerting. If you have not yet addressed Copy Fail (CVE-2026-31431), now would be a good time to treat both vulnerabilities as a combined remediation effort, given their similarity and overlapping mitigation steps.

References:
[1] https://github.com/V4bel/dirtyfrag/blob/master/assets/write-up.md
[2] https://xint.io/blog/copy-fail-linux-distributions
[3] https://www.openwall.com/lists/oss-security/2026/05/07/8
[4] https://blog.cloudlinux.com/dirty-frag-mitigation-and-kernel-update
[5] https://almalinux.org/blog/2026-05-07-dirty-frag/

-----------
Yee Ching Tok, Ph.D., ISC Handler
Personal Site
Mastodon
Twitter