(Headline article below) The comment below about a future version which can escape Docker containers is troubling. Though, you’d have to be running a package that got hijacked. Though, it does emphasize that you want to be very vigilant about what software you run, or who you allow to have access to your Linux computers. The only affected systems I have are a couple Raspberry Pis with stock kernels. This Debian server just got new kernel 6.12.85, so I’d imagine the Pi’s will get an update soon. You can use rpi-update to update to a newer kernel if concerned about a particular Pi.
“The POC exploit works out of the box today, but a future version that can escape from containers like Docker is promised soon,” writes Slashdot reader tylerni7. “Technical details are available here.”
Versions 10 Total
Default Status: affected
affected
- affected at 4.14
unaffected
- unaffected from 0 before 4.14
- unaffected from 5.10.254 through 5.10.*
- unaffected from 5.15.204 through 5.15.*
- unaffected from 6.1.170 through 6.1.*
- unaffected from 6.6.137 through 6.6.*
- unaffected from 6.12.85 through 6.12.*
- unaffected from 6.18.22 through 6.18.*
- unaffected from 6.19.12 through 6.19.*
- unaffected from 7.0
https://nerds.xyz/2026/04/copy-fail-linux-root-exploit/
By Brian Fagioli
I’m not gonna sugarcoat this one, folks. A new Linux kernel bug just dropped, and it’s the kind of thing that makes you stop and stare at your screen for a second. Not because it’s complicated, but because it isn’t.
The vulnerability, CVE-2026-31431, is being called “Copy Fail,” and yeah, the name fits. A tiny 732-byte script can give a regular user full root access. No race conditions. No timing tricks. No crashing the system ten times hoping one sticks. It just works. Every time.
That alone would be bad enough. But it gets worse the more you read.
This isn’t some obscure distro-specific issue either. It hits basically everything. Ubuntu, Amazon Linux, RHEL, SUSE. Same script, same result. You don’t need to tweak offsets or rebuild anything. You just run it and suddenly you’re root. That kind of reliability is rare in exploits, and it’s not something you want to see.
What really makes this one feel gross is how it works. The attacker doesn’t actually change files on disk. Instead, it quietly corrupts the page cache, which is what the system uses when it reads and executes files. So the file looks perfectly fine if you check it. Checksums match. Nothing appears modified. But in memory, it’s been altered.
And guess what the kernel trusts? That in-memory version.
So you take something like /usr/bin/su, which runs with elevated privileges, inject a few bytes into its cached copy, and then execute it. Boom. Root shell. The disk never changed, so your usual detection tools just shrug and move on.
That’s the part that really stings. It’s stealthy in a way that feels almost unfair.
We’ve seen scary Linux bugs before. Dirty COW was messy and unreliable. Dirty Pipe was clever but limited. This one is clean. Straight-line. Predictable. It doesn’t even try to hide how effective it is.
And then there’s the container angle, which might be the most unsettling piece of all. Because the page cache is shared, this isn’t just a local problem. In the right setup, this can jump across containers. That means a low-privilege process inside a container could potentially mess with the host or neighboring workloads. If you’re running multi-tenant infrastructure, that should make your stomach drop a bit.
The root cause is basically a bad assumption in the kernel’s crypto subsystem. A specific mode called authencesn writes a few bytes past where it should, and thanks to how the kernel wires things together with AF_ALG and splice, those bytes land directly in the cached contents of a file. That’s it. Four bytes in the wrong place, and the whole system falls apart.
What’s wild is how long this sat there. Years. Quietly. No alarms. No obvious signs. Just waiting for someone to connect the dots.
The fix is already being pushed, and it basically rips out the optimization that made this possible. Which is kind of the theme here, right? A performance tweak from years back ends up opening the door to something nasty.
So yeah, patch your systems. Immediately. Don’t wait. Don’t assume your distro has it handled already. Check.
Because this isn’t one of those “maybe exploitable in a lab” bugs. This is the opposite. It’s simple, portable, and reliable. That’s a bad combination.
Linux isn’t broken, but moments like this are a reminder that even the stuff we trust the most can have cracks. And sometimes those cracks are just four bytes wide.
You can learn more at the dedicated website here.