Acknowledgments: Special thanks to Jamie Levy, Tom Lawrence, Jim Deville, Tyler Bohlmann, and Shivangi Pandey for their contributions to this write-up.
TL;DR
It’s never a good day for administrators when a branded vulnerability drops, especially when multiple of them land in rapid fire. Over the last two weeks, security researchers independently discovered multiple vulnerabilities in the Linux kernel that allow an unprivileged user to easily gain root access (local privilege escalation). All of these named vulnerabilities pertain to the Linux kernel’s zero-copy functionality, and are named CopyFail (CVE-2026-31431), Dirty Frag (CVE-2026-43284 and CVE-2026-43500), and Fragnesia (CVE-2026-46300).
While these vulnerabilities require an attacker to have established access on a victim machine, and none allow for remote code execution, they are trivially easy to exploit. An attacker can abuse native tooling (e.g., Python with only the standard library), resulting in the attacker having administrator (root) access. Once an attacker gains root, they have full administrative access to the victim’s system, allowing them to install further malicious tooling, exfiltrate data owned by privileged users, or bypass security tooling.
Further complicating things for defenders is the widespread nature of these vulnerabilities; when they were first publicly announced, most popular Linux distributions were affected (given that they reside in core components in the kernel, which ship with virtually every distribution), with little time for kernel developers to patch and for distributions to roll out.
Cache rules everything around me
On April 29, 2026, researchers at Xint Code announced the CopyFail vulnerability and proof-of-concept (PoC) exploit, demonstrating the ease at which an unprivileged user could gain root. Days later on May 7, researcher Hyunwoo Kim announced the Dirty Frag vulnerabilities and PoC exploit, which, when chained together, have the same local privilege escalation result as CopyFail. On May 13, William Bowling of the V12 security team announced the Fragnesia vulnerability and PoC exploit, again leading to direct root access. All of these vulnerabilities were uncovered with the help of large language models, and were placed in the public knowledge shortly after discovery.
CopyFail is a vulnerability in the Linux kernel’s algif_aead crypto API, which allows a socket interface for authenticated encryption. This vulnerability was introduced to the 4.14 Linux kernel in 2017 via commit 72548b093ee3. The vulnerability comes as a result of a zero-copy optimization, when AEAD reuses the source memory as the destination. This allows an attacker to overwrite a cached file, namely a page cache, via the splice syscall.
Dirty Frag is a similar vulnerability, like CopyFail and 2022’s Dirty Pipe vulnerability. According to the author of the Dirty Frag exploit, “while Dirty Pipe overwrites struct pipe_buffer, Dirty Frag overwrites the frag of struct sk_buff”, hence the appearance of “frag” in the name. While CopyFail abuses the page cache of the algif_aead submodule, Dirty Frag affects the xfrm-ESP and the RxRPC submodules and their page cache. The Dirty Frag vulnerabilities were introduced to the Linux kernel in 2017 and 2023, respectively. The author further explains, “What both vulnerabilities have in common is that, on a zero-copy send path where splice() plants a reference to a page cache page that the attacker only has read access to into the frag slot of the sender side skb as is, 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”.
Fragnesia is related to the same area of the kernel and a variant of the Dirty Frag vulnerability. Fragnesia affects the XFRM ESP-in-TCP kernel subsystem. According to the Fragnesia PoC author, “it abuses a logic bug in the Linux XFRM ESP-in-TCP subsystem to achieve arbitrary byte writes into the kernel page cache of read-only files, without requiring any race condition”. Like the other vulnerabilities, successful exploitation of Fragnesia also leads to local privilege escalation and root access.
All of these vulnerabilities (CopyFail, Dirty Frag, Fragnesia and Dirty Pipe) suffer from the same weakness; a kernel subsystem, via a reference to a page cache, performs an in-place write which is corrupted, and the page-cache corruption is present to every reader of the underlying file. This allows an attacker to get access to a protected file and become root.
From hero to zero(copy)-day
An old programming joke goes “there are two hard problems in computer science: naming things, cache invalidation, and off-by-one errors”. While not strictly a cache invalidation issue, page caching is still hard, and today we are going to dive into the second part, abusing the page cache.
CopyFail, Dirty Frag, and Fragnesia belong to a wider family of vulnerabilities that rely on memory page cache corruption. This kind of attack was most recently seen in 2022’s Dirty Pipe vulnerability (CVE-2022-0847), which when successfully exploited also resulted in local privilege escalation. These exploits take advantage of zero-copy syscalls like sendfile, splice, and vmsplice, to populate the cache with poisoned data. Since the operating system has implicit trust in the contents of the page cache, any future requests to the target file (or pipe, or socket), now returns from this cache, and the poisoned data persists in the cache, invisible. One of the speed optimizations an operating system can take is that it looks at what is already in memory; what is insidious about these kinds of exploits is that they hook into the in-memory aspect of the vulnerability (the file that is read on-disk, e.g., the su binary, is unchanged, but its copy in memory is now corrupted).
So, what is zero-copy? This legitimate functionality has been around for a while in the Linux kernel, since at least kernel version 2.2, which was released in 1999. Zero-copy is one of those "hidden" performance boosters that underpins almost everything we do online, from streaming 4K video to high-frequency trading. At its core, zero-copy is about efficiency — specifically, eliminating the need for the CPU to move data between memory buffers, which significantly boosts system performance and throughput.
Every time data is moved the traditional way, the CPU burns cycles shuffling it around. Zero-copy lets the hardware (like the NIC) pull data directly from the kernel's memory without the CPU acting as an intermediary. What would have been 4 context switches and 4 data copies is reduced to typically two context switches and zero CPU-driven memory copies–hence "zero-copy."
Instead of making copies, we move data via Direct Memory Access (DMA), often by passing pointers/references to the existing kernel buffer rather than the data itself. This is distinct from the typical malloc or new command, and by design the data never even enters the application's memory region.
How does caching get involved here? The page cache is the kernel's way of keeping recently accessed disk data in RAM. When an application requests data, the kernel checks the page cache first; if the data isn't there, it reads from disk, populates the cache, and then returns the data to the app. Subsequent reads come straight from the cache until it's invalidated.
When an application uses a zero-copy call (like splice or sendfile), the kernel effectively says, "If the data you want isn't in the cache, fetch it into memory, then hand the other side a reference to read it directly." This is why these exploits target the cache – they don't modify data on disk; they change what your computer believes is equivalent to the data on disk.
Remediations
Thankfully, there are a few ways administrators and defenders can prevent these kinds of zero-copy-enabled local privilege escalation attacks from occurring. These exploits require an attacker to already have an initial foothold on the system, so typical protections against initial access apply here.
Specific remediations include patching to the latest kernel version your distribution offers (or, upgrading to a supported distribution that does). This is the most effective and long-term solution, as patches are being rolled out at the time of this writing.
CopyFail specific mitigations
The CopyFail announcement suggests patching first, but in workloads that don’t permit immediate patching, the following mitigation can be employed:
echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.conf
rmmod algif_aead
The CopyFail authors indicate that this will not impact most normal functionality, with the exception of: “userspace specifically configured to use AF_ALG — e.g. OpenSSL with the afalg engine explicitly enabled, some embedded crypto offload paths, or applications that bind aead/skcipher/hash sockets directly”.
Dirty Frag and Fragnesia specific mitigations
AWS’s advisory contains Dirty Frag mitigations, as well as the PoC for Fragnesia which includes the following:
Check if the modules are presently loaded:
lsmod | grep -E "esp4|esp6|rxrpc"
echo 'install esp4 /bin/false' >> /etc/modprobe.d/cve
dirtyfrag.conf
echo 'install esp6 /bin/false' >> /etc/modprobe.d/cve
dirtyfrag.conf
echo 'install rxrpc /bin/false' >> /etc/modprobe.d/cve
dirtyfrag.conf
Unload them if they’re active:
rmmod esp4 esp6 rxrpc
Tom Lawrence has a great write-up on these mitigations, and if you need to maintain an IPSec instance, please check the mitigations here as well as from AWS’s advisory.
sysctl -w kernel.modules_disabled=1
sysctl -w user.max_user_namespaces=0
The Ubuntu blog indicates that IPsec ESP and RxRPC use cases will be impacted by these mitigations, specifically:
-
IPsec deployments. These are common with VPN implementations such as StrongSwan.
-
AFS (Andrew File System) or another application of RxRPC.
As the vulnerabilities are independent, disabling only the esp4/esp6 modules or only the rxrpc modules would leave the remaining ones exploitable.
Other practical considerations
One of the security features of the Linux kernel is LSM, or the Linux Security Module. This can be combined with one of Linux’s super-powers, eBPF, in the form of LSM BPF. This combination allows security practitioners to hook into various aspects of the kernel to provide directed, powerful mitigations. However, not all Linux distributions come with LSM BPF enabled out of the box.
With regard to the vulnerabilities outlined in this blog, BPF-LSM provides for responsive security by actively blocking access to sockets (AF_ALG), or syscalls (splice). Without LSM BPF, securing a system involves a patchwork of efforts. These too are subject to what a particular distribution offers.
The Linux Security Module is a framework that has evolved over time by the common need to provide security for varying purposes. Historically, Linux only provides Discretionary Access Control (DAC), if the attacker gains access to a user, then they have access to everything that user owns.
The rise of containerization, which enables users to run environments with different security needs forced another advancement; stacking. LSM is extensible, it allows for the "stacking" multiple modules in a chain to assess if permissions should be granted. eBPF, a framework for hooking into various parts of the kernel in a guaranteed safe way, further amplifies LSM capabilities. It allows one to dynamically load and enforce custom security policies on the fly.
We strongly encourage the Linux community and distribution maintainers to ensure LSM BPF is compiled into the kernel and enabled at boot to provide the protections outlined above.
