Vulnerability spotlight: CopyFail and DirtyFrag

What CopyFail and DirtyFrag are and why quickly patching them mattered.

Hello internet, Matt here. This week’s post is going to be about something interesting I found out while talking to some people on the Linux forums last week. I will talk about the CopyFail and DirtyFrag vulnerabilities in Linux. I find them to be interesting subjects from talking about and they are very relevant to security and privacy too. Having them on your system can literally make or break your system without you even knowing it.

If you’ve been around Linux security discussions for a while, you know that kernel privilege‑escalation bugs come and go. Most are annoying, some are impactful, and a very small number deserve the kind of reaction that makes sysadmins cancel weekend plans because the whole world is at a high risk of losing everything. CopyFail and DirtyFrag fall squarely into that last category. They aren’t just “another LPE.” They’re reminders of how fragile trust can be once the kernel itself stops enforcing boundaries.

Background: Why Kernel Bugs Hit Different

Before diving into the specifics, it’s worth laying out why these vulnerabilities caused so much noise. A local privilege escalation (LPE) bug sounds like less of a big deal than it is. Local privilage escalation implies that the attacker needs to be squarely in the machine. While this is still the case, our modern workflows provide many new vectors for this to happen. Other than having access to the bare metal system, an attacker can also exploit these by exploiting any of the following:

• Containers sharing a kernel

• CI runners executing untrusted pull requests

• Multi‑tenant servers

• WSL instances on developer laptops

• Low‑privileged service accounts compromised via web exploits

Once you have a reliable kernel LPE, all of those isolation boundaries collapse. That is the common theme tying CopyFail and DirtyFrag together. You’d do well to be scared of this one.

Both vulnerabilities abuse a class of kernel logic errors involving the page cache. This is important: the page cache holds in‑memory copies of files, including executables. If an attacker can tamper with those in-memory copies without modifying the file on disk, traditional file integrity monitoring and forensics may see nothing wrong.

That detail alone should already make you uncomfortable. I know it makes me uncomfortable.

What CopyFail Actually Did

CopyFail, tracked as CVE‑2026‑31431, was disclosed publicly at the end of April 2026. It turned out to be one of the most universal Linux privilege escalation flaws ever disclosed. I saw messages from everywhere and every company/organization saying that they were hard at work fixing the bug as soon as they heard about it.

At a technical level, CopyFail is a logic bug, not a race condition or memory corruption issue. The bug lives in the Linux kernel’s cryptographic subsystem, specifically the AF_ALG interface used for authenticated encryption operations. A logic error introduced in 2017 allowed an unprivileged user to perform a controlled 4‑byte write into the page cache of any readable file.

Four bytes doesn’t sound like much—until you remember how binaries work.

By carefully choosing where those four bytes land, an attacker can alter the in-memory version of a setuid binary such as su. When that binary is executed, the modified page cache is used, not the clean copy on disk. The file on disk remains unchanged, the page isn’t marked dirty, and nothing gets written back to storage. From a forensic perspective, that’s nightmarish because nothing is changed and everything on the disk looks clean; all of the hashes match and nothing is suspicious. Another bad part that really caught my eye is that, if I reboot, everything will look like nothing ever happened!

Even worse, the exploit was fully deterministic. No timing window. No kernel version‑specific offsets. The same short Python script worked across nearly every major distribution shipped since 2017. If that’s not scary for your data, then I don’t know what is.

Why CopyFail Required Immediate Patching

CopyFail checked every box that defenders hate because it not only works across distributions with no modification, but it also allows instant root from an unprivileged user, bypasses file integrity controls, and enables container escapes and cross‑tenant attacks.

This wasn’t a bug you could “accept the risk” on for single‑user systems and move on. If your environment involved shared infrastructure in any form, CopyFail dramatically changed your threat model overnight.

The Linux kernel team responded relatively quickly in upstream kernels, but the real delay came from distribution packaging and backporting. That gap—between upstream fix and downstream availability—is where real-world risk lived.

Mitigations such as disabling the algif_aead kernel module were widely recommended, but they came with tradeoffs and weren’t universally deployable.

CopyFail made it painfully clear that “local-only” bugs can still be ecosystem‑level events.

Enter DirtyFrag

If CopyFail wasn’t enough excitement for one year, DirtyFrag showed up barely a week later. Right after we thought we were done with a bad kernel vulnerability, we got another one.

DirtyFrag is not a single vulnerability but a chained exploit combining two kernel flaws:

• A page‑cache write issue in the xfrm/ESP IPsec subsystem

• A page‑cache write issue in the RxRPC subsystem

When chained together, they enable reliable root privilege escalation on most major Linux distributions.

What makes DirtyFrag especially unsettling is that it deliberately extends the same bug class as CopyFail and Dirty Pipe. It targets fragmented memory behavior and page cache manipulation in networking code, instead of crypto code—but the end result is the same.

Unprivileged user in. Root shell out.

How DirtyFrag Differs from CopyFail

Although the outcome is similar, DirtyFrag differs from CopyFail in a few important ways.

First, DirtyFrag abuses networking subsystems (IPsec and RxRPC) rather than crypto APIs. This means systems that never disabled AF_ALG as a CopyFail mitigation could still be vulnerable.

Second, DirtyFrag improves reliability in locked‑down environments. Some distributions restrict unprivileged namespace creation, which blocks certain exploit paths. DirtyFrag works around those restrictions by chaining vulnerabilities with complementary requirements. Where one exploit path fails, the other succeeds.

Third—and this is important—DirtyFrag landed before patches were ready.

A disclosure embargo was broken, proof‑of‑concept code leaked, and defenders were suddenly dealing with an actively exploited zero‑day. That alone escalated the severity of the situation.

Why DirtyFrag Was Even More Urgent

DirtyFrag inherited all the risk of CopyFail and added several new problems on top:

• No initial patch availability

• Public exploit code immediately available

• Demonstrated in‑the‑wild experimentation

• Reliable, non‑crashing exploitation

Microsoft and other monitoring teams quickly reported post‑compromise usage patterns consistent with DirtyFrag and CopyFail exploitation. That’s the worst‑case scenario: a bug that’s both easy to weaponize and useful in real attacker workflows.

As with CopyFail, exploitation doesn’t require remote access by itself—but attackers already have countless ways to get that foothold. Web shells, stolen credentials, container breakouts, supply‑chain compromises—you name it.

Once DirtyFrag enters the picture, all of those initial compromises escalate into full system ownership.

Patch Velocity and Community Response

One thing worth giving the Linux ecosystem credit for is how fast the response eventually became.

Once DirtyFrag was fully disclosed, just like CopyFail, we not only saw patches swiftly released, we also saw that distributions issued mitigations in the blink of an eye and vendors made backports their number one priority.

Temporary mitigations involved disabling vulnerable kernel modules such as esp4, esp6, and rxrpc. Of course, that’s easier said than done if you rely on IPsec VPNs or AFS. As always, security fixes have operational costs.

What stood out to me is how openly the community discussed what went wrong—not just in the code, but in the disclosure process. Broken embargoes, partial disclosures, and researchers reverse‑engineering patches all contributed to the chaos.

These events reignited debates around responsible disclosure in open‑source projects, especially when fixes require coordination across dozens of vendors.

Security and Privacy Implications

From a privacy and trust standpoint, both vulnerabilities highlight a harsh reality: you can’t trust a bad kernel. With flaws like these, attackers have very easy ways to access the entire system, with which they can do many things we wouldn’t want them to. They can wreak havoc on the system, turning off all logging, remove security tooling, enable backdoors to ensure persistence, and do many other things to steal the information that is so valuable. This makes it even more important to ensure that our kernels are safe and secure at all times.

And because both CopyFail and DirtyFrag can operate without obvious disk artifacts, they challenge traditional incident response assumptions.

Conclusion

CopyFail and DirtyFrag will go down as case studies in how simple logic bugs can have massive systemic impact. Neither relied on exotic exploitation techniques; neither required esoteric hardware behavior. Both quietly sat in the kernel for years, waiting for someone to notice the pattern.

For me, the takeaway isn’t “Linux is insecure.” It’s that complex systems fail in complex ways, and the kernel is still one of the highest‑impact layers we trust.

If you’re running Linux in shared, multi‑tenant, containerized, or CI‑driven environments, these bugs weren’t edge cases. They were wake‑up calls.

Patch fast. Audit assumptions. And never underestimate what “just a local bug” can turn into.

As always, thanks for reading—and until next time, stay curious and stay patched. Matt, OUT!