Copy Fail, Dirty Frag, and Friends – Linux Kernel Vulnerability Coordination in the Modern World

Will Dormann

Background

On opposing ends of the disclosure spectrum are non-disclosure and full-disclosure strategies. With non-disclosure, the vendor is not told about a known vulnerability. With full disclosure, the public is told about a vulnerability, and this is the point that the vendor may find out about it, leading to the vulnerability being referred to as a 0day vulnerability as the vendor had zero days of advance warning to be able to work on a fix. Coordinated Vulnerability Disclosure (CVD) is a process that aims to balance the risk of vulnerabilities being disclosed, giving vendors time to work on preparing fixes, and leading to an eventual disclosure of some amount of vulnerability details.

In the recent weeks, multiple Linux kernel local privilege escalation (LPE) exploits have been released. Each vulnerability took a slightly different path through the disclosure process. None of the cases resulted in an ideal situation for defenders.

Copy Fail

The first of the vulnerabilities, referred to as “Copy Fail” was released at the copy.fail website on April 29, 2026. The vulnerability, a logic bug in authencesn, results in the ability to write 4 bytes at a time into the Linux page cache. This can result in the ability to modify the contents of files loaded into the Linux kernel. This vulnerability affects most Linux distributions, and no distribution had an explicit fix prepared at the time that the vulnerability and exploit for it was published.

The original Copy Fail exploit existed as a 732-byte python script. Successful exploitation resulted in the setuid root su binary being modified to spawn a root shell.

Copy Fail was fixed in the main linux kernel with commit a664bf3 on March 31, 2026.

The Coordination

The organization behind Copy Fail, Theori, coordinated the vulnerability with the Linux kernel team only. No Linux distribution vendor was made aware of the vulnerability before public disclosure because the Linux kernel team does not give Linux distribution vendors advance information about vulnerabilities. Brian Pak of Theori has a damage-control thread that explains the actions that they took. Specifically, that because Qualys will be coordinating Linux kernels with only the Linux kernel security team, then this should be fine for them as well. It should be noted that the linux-distros mailing list was explicitly created for the purpose of coordinating vulnerabilities among major Linux distributions, and that its use may have minimized the damage caused by the public release of the Copy Fail vulnerability and exploit.

Since the Linux kernel team became a CNA, there has been a flood of Linux kernel CVEs. With the case of Copy Fail, CVE-2026-31431 was assigned merely one week before public disclosure. So even the most diligent Linux distribution vendors would need to have picked out this particular CVE and rushed to get a fix out to their users. The fact that Theori had a working exploit and plans to publicly release a named-vulnerability website to disclose it was definitely not conveyed to the Linux distribution vendors. So nothing about CVE-2026-31431 would have made it stood out from the sea of other Linux kernel CVEs.

Lackluster vulnerability coordination aside, the Theori team published the copy.fail website and demonstrated successful exploitation on four different Linux distributions:

Ubuntu 24.04
Amazon Linux 2023
Red Hat Enterprise Linux (RHEL) 10.1
SUSE 16

At the time that the copy.fail website was published, it made the statement:

Most major distributions are shipping the fix now.

But at this time, none of the four distributions that they demonstrated themselves had a fix available. This lack of attention to detail is disappointing and suggests that the intention of Theori was not to improve Linux security, but rather to get attention. And one might argue that they were successful in doing this, to the detriment of Linux system defenders. Luckily Red Hat published a mitigation that could block the exploit. Specifically, to add to the linux kernel boot arguments (e.g. via Grub configuration), one of:

initcall_blacklist=algif_aead_init

initcall_blacklist=af_alg_init

initcall_blacklist=crypto_authenc_esn_module_init

While the copy.fail website suggested a mitigation, it would only work on Linux distributions that provide algif_aead as a loadable kernel module, as opposed to being compiled into the kernel like RHEL does. Again, the Copy Fail disclosure lacked polish that would have been possible with proper coordination.

Dirty Frag

Shortly after the release of Copy Fail, an exploit called Dirty Frag was released. Similar to Copy Fail, Dirty Frag results in an unprivileged user being able to overwrite data in the Linux page cache. This allows such users to achieve LPE by being able to overwrite in-memory copies of /etc/passwd or /usr/bin/su.

The xfrm-ESP Page-Cache Write vulnerability CVE-2026-43284 was patched with commit f4c50a4 on May 5, 2026.

The RxRPC Page-Cache Write vulnerability CVE-2026-43500 was patched with commit aa54b1d on May 10, 2026.

The Coordination

Unlike Copy Fail, Dirty Frag took the path of proper coordination by way of the linux-distros mailing list. However, due to what was referred to as a broken embargo, Dirty Frag was published on the same day that it was sent to linux-distros. This resulted in a similar outcome to Copy Fail, with respect to the situation it put defenders in.

The mitigation for Dirty Frag is to run the following command as root:

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; echo 3 > /proc/sys/vm/drop_caches; true”

Copy Fail 2

Copy Fail 2, while building on the name for Copy Fail, is actually an independent discovery of one of the Dirty Frag vulnerabilities. The publication of Copy Fail 2 is reportedly what was considered by the Dirty Frag coordinators as a breaking of the embargo, which triggered its early disclosure. But as the above-linked post to oss-security points out, the Copy Fail 2 author was not a part of the embargoed discussion on linux-distros. And as such, the release of Copy Fail 2 should probably not have been considered a break of the embargo. Sure, the outcome was the same in that some of the embargoed information was made public. But this is not a break of the embargo. An embargo break involves a breach of trust by a party participating in the embargo, but this was apparently an independent discovery, which means no trust was broken.

The Coordination

Copy Fail 2 was not coordinated, but rather was disclosed publicly in “full disclosure” style.

The mitigation for Copy Fail 2 is the same as Dirty Frag, which is to run the following command as root:

Conclusion

It’s hard to imagine that nearly 25 years after Microsoft discussed the concept of “responsible” disclosure that we’d be having discussions about vulnerability coordination and disclosure, but here we are. Since then, the term “CVD” has gained traction, as it avoids the word “responsible,” which tends to favor vendor-centric perspective in a subjective and moralizing way.

The Linux kernel is perhaps a worst case scenario of how vulnerability coordination can happen. Specifically, in that while one can report a vulnerability to the Linux kernel maintainers, the process of getting the vulnerability information to the software maintainers that use the Linux kernel is quite lacking. Officially, it’s up to each user (e.g. a Linux distribution) of the Linux kernel to notice and pick up vulnerabilities in the Linux kernel. If the Linux kernel maintainers had their way, this would be done by every Linux distribution always using an up-to-date supported kernel version. But that’s not the way that the real world works. Linux distros often use an older “distro-approved” kernel for their OS, and they backport fixes to their kernel version as vulnerabilities are disclosed. For example, RHEL 9.7 was released in late 2025, yet it uses a Linux 5.14.0 kernel, which is about 5 years old by now. But it’s not a stock 5.14.0 kernel. It has patches applied by Red Hat, but keeping the 5.14.0 version number. How the Linux kernel CNA’s mindset of “every kernel bug gets a CVE unless it has been proven to not be a security issue” and Red Hat’s mindset of “we backport fixes with security impacts into our older kernels” can both coexist in the same world is perhaps a topic that warrants its own discussion.

The recent Linux LPE vulnerabilities and associated exploits all took different paths through the disclosure process, and each one of them resulted in Linux distribution vendors being blindsided and Linux system defenders being at a loss for proper fixes. Different people or organizations have different motivations for selecting a disclosure path. And the above three cases show a range of paths, which interestingly each led to a similar outcome in that Linux distributions were blindsided and Linux defenders were left scrambling.

It is believed by many that CVD is the path of least pain when it comes to dealing with vulnerabilities. Organizations like CISA even have a landing page for their Coordinated Vulnerability Disclosure Program, if you’d like to have them take care of the coordination.

These Linux kernel LPEs are perhaps the worst case scenarios. In the end, patches will get released, and end-user systems will get updated, and business will go on as usual.