Fixing LPEs on the Fly: Mitigating CopyFail and DirtyFrag with eBPF

aettern — Mon, 13 Jul 2026 06:19:01 +0000

In late April and early May of 2026, two Linux local privilege escalation bugs landed a week apart named CopyFail (CVE-2026-31431, disclosed April 29) and DirtyFrag (CVE-2026-43284 / CVE-2026-43500, disclosed May 7). Both let an unprivileged local user become root, both were deterministic which means that it does not require no race conditions or specific timing or chain of actions for it to work. Both had public PoC released within days of disclosure. That combination of being reliable, public and unpatched is about as bad as LPEs get.

The "official" fix for both was the same story we always receive for this sort: wait for a patched kernel, reboot. Which is fine if you are running a laptop but not if you are running a fleet of production servers, a Kubernetes cluster full of untrusted tenant workloads, or literally anything where a reboot means a maintenance window, a failover or an outage nobody signed up for that week.

This caught my interest and I came up with something called copyfrag-fuse, a small BPF-LSM program that blocks both exploits at runtime, without touching the kernel version and also does not require a reboot. This writeup covers what the bugs actually do, why the standard mitigations are very fragile, how my fix works and the tradeoffs I made along the way.

Here's link to the repo btw: github.com/aettern/copyfrag-fuse

This was heavily inspired by the approaches that Cloudflare brought up with their writeup on CopyFail and also the writeup of Miggo Security by Rafael David Tinoco and it's genuinely what made it all click for me.

And at the time of writing this, the patches have already been released by every major distro so make sure your systems are up to date.

The Exploits, and why they matter

Both CopyFail and DirtyFrag boil down to the same primitive which is an unprivileged process tricking the linux kernel into performing an in-place cryptographic operation over memory pages that it doesn't own and specifically ones that are sitting in the shared page cache. If you can get to land a controlled write into the page cache of a file like /usr/bin/su, then congrats you have just modified the binary in memory for every process that runs it next as they all share the same page cache. Run it once, and you get a root shell. And all this happens without ever touching the file on the disk btw.

CopyFail does it through AF_ALG, the socket interface to the kernel's crypto API. It abuses an in-place optimization added to the algif_aead module that was implemented back in 2017.

The flow of the attack is as follows:

splice() is used to map a target file's page cache into the crypto scatterlist, so the kernel treats those real page-cache pages as its own scratch space.
The AEAD decrypt operation is triggered. authencesn performs a 4-byte scratch write past the intended output region during decryption — and because of step 1, that write lands directly in the spliced page-cache page instead of a private buffer.
This gives the attacker a controlled 4 byte write where he gets to pick the file, the offset, and the value too.
Do that a few hundred times against /usr/bin/su and you've written working shellcode into a setuid-root-binary's in memory copy.

The entire exploit is extremely small as it's just a 732 byte Python script, and it's universal

For a way more detailed explanation, check out Xint.io excellent article on CopyFail and to get the exploit code itself check out the dedicated page created by their team copy.fail

DirtyFrag is also kinda similar but instead of using AF_ALG it goes through the IPsec ESP Platform (esp4/esp6) or the RxRPC transport which is used by AFS and the kernel's Kerberos path. The base idea is still the same as this also decrypts over pages the kernel doesn't privately own that is reached through splice()/sendfile() and we get the same page cache controlled write. This variant showed up a week after CopyFail, which is not a huge surprise as once an attack vector goes public then people go looking for its siblings.

To get a look at the exploit code check out the github repo of DirtyFrag

Impact-wise, this is about as bad as LPE bugs get as they have no race condition to win, no kernel version pinning required, works across basically every mainstream distro shipping a kernel from 2017 onward and on top of that it's very stealthy too because the change never touches the disk as the file integrity monitoring that checksums files on disk won't see it. Getting a LPE on a computer you already own is not a big deal but in a container or multi-tenant host environment, the page cache is shared with the host, so this isn't just an LPE but a potential container-escape primitive too.

What were the standard mitigations and why they fall short

The advisories that went out for both bugs came up with mostly the same thing that is disable the vulnerable kernel module.

echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.conf
rmmod algif_aead 2>/dev/null || true

and for DirtyFrag it was esp4, esp6, and rxrpc. These were the recommendation that came up when these went public and it's a completely reasonable thing to suggest as it is simple and it does stop the exploit completely.

But it has two real problems,

It silently doesn't work on a lot of distros. On RHEL family of distros, algif_aead is compiled directly into the kernel (CONFIG_CRYPTO_USER_API_AEAD=y), and is not built as a loadable module. So even if the modprobe blacklisting and rmmod returned without any error are report success still they do nothing because there's no module to block or remove there. This leads to dangerous failure because it's invisible unless someone actually takes a look into it.

Even if we get the module to get disabled, then it takes down the entire subsystem for everyone. If we disable algif_aead it then breaks every legitimate userspace program using AEAD ciphers through the kernel crypto API such as disk encryption helpers and so on. Disable esp4/esp6 and we break IPsec tunnels outright used by VPNs. Disable rxrpc and AFS clients stop working. If the environment uses any of these especially something like IPsec then we are trading an LPE for an outage.

Then the second one is the reboot problem. Cloudflare's own write-up on CopyFail has a good point on this as even for a company with a fast kernel release pipeline, the upstream fix had already been merged into stable LTS lines weeks before disclosure but they were still stuck waiting for it to land in their specifc build, because the fix hadn't been backported to the specific LTS series they were actually running. According to that write-up their normal process is to reboot on a rolling 4 week cycle which is not slow at all but it wasn't fast enough for a same-day exploit. If a company such as Cloudflare can have that gap then most of us could have had it worse with shared hosting boxes, long running stateful services etc... where the statement "just reboot it" is much more complex process than a command.

How my fix works: behavior, not signatures

The basic approach of a security tooling at most times would be to look for the signature and block it. For example, if some program is using AF_ALG or splicing specific files such as /etc/passwd it just gets outright blocked. Both of these are weak counter-measures. This brings the whole socket family down as it is just the module-disable mitigation in a different form. And file tampering detection is totally dodged because the vulnerability does not care about which file backs the target page and if it just points it to a different exploit at a different file then the detection never fires.

But one thing that is uncommon in these exploits is the the pattern of how the socket options et configured. This is an amazing find by Miggo Engineering btw. So, Legitimate users of these subsytems only behave like these,

A real crypto application sets ALG_SET_KEY once per socket, with an actual key.
A real VPN or IPsec stack configures UDP_ENCAP on a very few long-lived sockets.
A real AFS client or Kerberos session sets RXRPC_SECURITY_KEY and RXRPC_MIN_SECURITY_LEVEL once per connection.

None of these look anything like what these exploits do, which is spray the same option, with a value across many short-lived sockets, over and over in a tight loop as the write primitive is only 4 bytes at a time and it needs a lot of repetitions to land a useful payload.

My eBPF LSM module solution CopyFrag-Fuse hooks security_socket_setsockopt, the LSM hook that SELinux and AppArmor have used for years via BPF_PROG_TYPE_LSM. This is a really good attachment point for a couple of reasons as it fires at the exact decison point cause when the setsockopt() is called, this hook runs before the kernel even requests that socket change. At that moment, this program can exactly see what's being requested with data such as which socket, which level and what specific option it is trying to set. As it runs before the completion of the change, the program can return a negative value like -EPERM which mean "permission denied" and the kernel never let's it goes through.

And for each process, the program tracks the state per relevant socket option such as a timestamp of the last call and a count. So, if a process makes four or more of the flagged option calls: ALG_SET_KEY, UDP_ENCAP, RXRPC_SECURITY_KEY, RXRPC_MIN_SECURITY_LEVEL within a one second window then it gets outright blocked with -EPERM.

During normal usage, it gets set once, maybe twice if it retries the connection but most of the times it never gets close to that threshold. Both CopyFail and DirtyFrag which needs rapid repetition to build up its write, hits it almost immediately.

One good property here is that this needs zero knowledge of which file or binary is being targeted. It doesn't care if the attacker point the exploit at /usr/bin/su or some other file that we have never heard of as the detection is entirely in the calling pattern and not the target.

Why these design decisions specifically

Why BPF-LSM and not a tracepoint or kprobe? A kprobe/tracepoint program can only observe a syscall taking place but not change it's outcome so you only get visibility not prevention. We'll need a separate mechanism for that which just makes it more messier. Meanwhile attaching a LSM Hook and returning -EPERM blocks the call just like SELinux and AppArmor before the damage even happens.

Why socket_setsockopt specifically? I did consider hooking it to splice() directly since that's what's used to do the page-cache write itself. The tradeoff is that it's being used by many legitimate code so it will just end up with a lot of false-positives only.

Setup & Usage

For step by step instructions for setup and usage of this check out the github repo which has the code and all the instructions necessary.

github.com/aettern/copyfrag-fuse

Where this is headed

The thing that struck me the most isn't the exploit mechanincs but instead the fact that CopyFail was reportedly found within an hour of using an AI assisited process. This bug sat in the code for almost a decade and it's been shipped across every major distro since 2017 and it only took an hour for the AI to find it.

This completely changes the math on old legacy kernel code. If discovery gets faster and cheaper then the gap between disclosure and patch matters more. I don't think runtime mitigations like copyfrag-fuse will replace patching. But if the next one of these drops on a Friday night and the vendor kernel is three weeks out, then having something we can drop in without a reboot will come in handy always.