New Linux 'Copy Fail' Vulnerability Enables Root Access On Major Distros (copy.fail) 50
A newly disclosed Linux kernel flaw dubbed "Copy Fail" can let a local, unprivileged attacker gain root access on major Linux distributions, with researchers claiming the bug affects kernels shipped since 2017. "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." Slashdot reader BrianFagioli shares a report from NERDS.xyz: A newly disclosed Linux kernel vulnerability called Copy Fail (CVE-2026-31431) allows an unprivileged user to gain root access using a tiny 732-byte script, and it works with unsettling consistency across major distributions. Unlike older exploits that relied on race conditions or fragile timing, this one is a straight-line logic flaw in the kernel's crypto subsystem. It abuses AF_ALG sockets and splice to overwrite a few bytes in the page cache of a target file, such as /usr/bin/su. Because the kernel executes from the page cache, not directly from disk, the attacker can inject code into a setuid binary in memory and immediately escalate privileges.
What makes this especially concerning is how quiet it is. The file on disk remains unchanged, so standard integrity checks see nothing wrong, while the in-memory version has already been tampered with. The same primitive can also cross container boundaries since the page cache is shared, raising the stakes for multi-tenant environments and Kubernetes nodes. The underlying issue traces back to an in-place optimization added years ago, now being rolled back as part of the fix. Until patched kernels are widely deployed, this is one of those bugs that feels less like a theoretical risk and more like a practical, reliable path to full system compromise.
What makes this especially concerning is how quiet it is. The file on disk remains unchanged, so standard integrity checks see nothing wrong, while the in-memory version has already been tampered with. The same primitive can also cross container boundaries since the page cache is shared, raising the stakes for multi-tenant environments and Kubernetes nodes. The underlying issue traces back to an in-place optimization added years ago, now being rolled back as part of the fix. Until patched kernels are widely deployed, this is one of those bugs that feels less like a theoretical risk and more like a practical, reliable path to full system compromise.
Temporary mitigation: (Score:2)
Blacklist kernel module "algif_aead" ...you probably weren't using it anyway.
Re: Temporary mitigation: (Score:1)
Note that this is a local exploit (Score:1, Informative)
If an attacker gets this far, you have already messed up. Still should be patched ASAP.
Re: (Score:3)
If an attacker gets this far, you have already messed up.
Yes, because there is no such thing as a shared machine.
Seriously?
Re: (Score:2)
Re: Note that this is a local exploit (Score:4, Funny)
Re: Note that this is a local exploit (Score:3, Insightful)
I don't give out login accounts to people I don't trust with root. If you need to run something, I expose it as a sandboxed web service and make damn sure you're authenticated to use it.
Re: (Score:2)
Indeed.
Re: (Score:2)
Did I say there was no danger or not to patch? No. But you have to scream nonsense anyways. Pathetic.
Re: Note that this is a local exploit (Score:2)
Re: (Score:3)
The reason is because the kernel/userland interface is huge and was not designed with security in mind (it was designed for efficiency, functionality, and sometimes outright braindeadedness). Even OpenBSD doesn't count local privilege escalation exploits, only remote exploits.
Re: (Score:2)
Indeed. But there are a lot of people that have no clue about IT security, but are unaware of that. And hence the same stupid comments every time.
Re: (Score:2)
Yes, comments like
If an attacker gets this far, you have already messed up.
"this far" quite obviously meaning "has the ability to login to the system"
Re:Note that this is a local exploit (Score:4, Informative)
I hate how this reasoning persists. It is just so disconnected from the real world.
So should large organizations just not bother with least privilege and normal users? Everyone might as well be root, if one with bad intentions gets access to a system, well they should be assumed to just be root anyways?
I mean, in a company with even 100 people, if one of their accounts gets compromised, or one of them goes rogue, "you have already messed up" really isn't the point. I used to run a data ingest system where we gave limited shell accounts to somewhere around 1,000 clients, plenty of similar but much larger systems are out there. No one *at my company* had messed up in any way if one of those accounts went rogue. Tons of systems like that exist, it's not some edge case.
Re: (Score:2)
Again, no one saying this is no big deal. What they're saying is not every Dick and Harry off IRC can r00t your box.
Usually it's people you've already vetted to some degree, whose personal information you have, who will still leave a trace of activity, if you log your system activity remotely, etc. That's a very different scenario from randomly exploiting some system from behind 4 public proxies.
Re: (Score:2)
Indeed. It also means that on machines were you have no hostile users, you have more time to patch. One of the most important things in such a such a situation as this is to patch the most vulnerable machines first.
Re: (Score:2)
Everyone might as well be root, if one with bad intentions gets access to a system, well they should be assumed to just be root anyways?
That's how AWS does it.
I used to run a data ingest system where we gave limited shell accounts to somewhere around 1,000 clients, plenty of similar but much larger systems are out there. No one *at my company* had messed up in any way if one of those accounts went rogue.
If they have hacking skills, the "limited shell access" wouldn't be limited long. Giving someone local access is insecure.
Re:Note that this is a local exploit (Score:4, Interesting)
We've been in the cloud era 15 years now. Docker hosts, Kubernetes pods, Lambdas, Even old fashion cpanel hosts. All of these are at risk, even if the users are otherwise doing everything right.
Re: (Score:3)
We've been in the cloud era 15 years now. Docker hosts, Kubernetes pods, Lambdas, Even old fashion cpanel hosts. All of these are at risk, even if the users are otherwise doing everything right.
The people who have shell access to the k8s hypervisor or worker nodes probably have root access anyway. Getting root access to the container pods does not buy you much beyond what you get by getting access to the service's shell account. At that point you can already read whatever secrets were injected via environment variables, read application log files, etc.
The main vulnerability strikes me as being on shared untrusted jump boxes, or like you mentioned, old school cpanel multiuser shell-based hosting
Re: (Score:2)
Imagine running a research HPC system for academics right now.
For the vast majority of cases, sure. For some specific types of systems, it's very normal to have only semi-restricted access, folks who like to poke things as regular users and specific interest from big players who'd love access to the research data those users aren't even trying to protect.
Re: (Score:2)
There was a catastrophic auth bypass CVE for CPanel the same day.
Chaining is just normal these days.
Re: (Score:3)
It relies upon the ability to run a shell script. So essentially any cascading list of failures can result in this exploit being used. If Chrome has a buffer overflow, you can get root from that. If a library you're using via NPM, Composer, Rubygems, PIP, etc, is ever compromised, you'll be exploitable when you add it to your project, even though you never went near sudo.
Not to mention the fact that it's become ridiculously popular lately to instruct people to install, for example, new programming languages
Re: (Score:2)
Which brings me to "you already have screwed up".
Re: (Score:3)
No, right now it's literally impossible to be a professional in the industry right now and not use something like NPM, Composer, or whatever. Most of us don't have any choice. And likewise, if someone finds an exploit in a common web browser and you don't know this, how the fuck are you supposed to mitigate from it?
Configurable? (Score:2)
Could they have made that feature a configuration switch instead of hardwiring it in? That way it could be quickly undone if it proved a problem. Or would the branching time to check the switch defeat the purpose of optimization?
Yup, this works on our student lab machines (Score:3)
Not that I don't trust our students*, but - yeah I see lots of patching in my future...
*Even without bad intentions, these are engineering students and have been known to try stupid stuff before
And this is why (Score:1)
Immutable Linux distros are superior - especially if the machine is a shared. Almost all the big, regular, mutable distros suck balls - especially Ubuntu.
Re: And this is why (Score:4, Informative)
Re: (Score:2)
Doesn't matter. The attack still fails completely.
Re: And this is why (Score:2)
Re: (Score:2)
W^X [wikipedia.org]? As implemented in PaX, Exec Shield, SELinux. Which all Linux distros have and no Linux user ever uninstalls or disables. Or something.
Immutability and W^X don't prevent this (Score:2)
Immutable distributions, in Linux parlance, run on a read-only root filesystem that is swapped for the next boot if there are any updates. Usually, you can use one or more snapshots to roll back to the (or a) previous version if an update fails.
What this attack is doing is not helped by immutability under that definition: it's entirely in memory and works only as long as the target executable is in memory. It first reads the target executable into the disk cache and asks a specific kernel module to encrypt
Re: (Score:2)
It seems to not matter, the few immutable distros I tested on prevent the attack from working. Unless they saw the flaw before it was published and patched it themselves.
Re: (Score:2)
It seems not every distribution ships with the vulnerable module, built-in or loadable, either. That could be another factor, too.
On my Ubuntu 26.04 host, all patched up to yesterday, lsmod as root shows only algif_hash and algif_skcipher, not algif_aead.
Asleep at the wheel (Score:3, Interesting)
Re: (Score:1)
Thanks for not calling us neckbeards. :)
Re: (Score:2)
Re: (Score:2)
Well, it fits me. (Even though I'm more a user than a system programmer.)
conditionally dangerous bug (Score:2)
enterprise mitigation (Score:3)
For older enterprise distros, this mitigation method:
# echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.conf
# rmmod algif_aead
Does not work because algif_aead is built into the kernels.
However, this does work:
# grubby --update-kernel=ALL --args="initcall_blacklist=algif_aead_init"
Then reboot. It will disable the vulnerable module that is built-in. I am not sure if there are any negative ramifications of having algif_aead disabled, though. Does anyone know?
Updating to a patched kernel is, of course, the better course.
See https://seclists.org/oss-sec/2... [seclists.org]
Re: (Score:2)
>"I am not sure if there are any negative ramifications of having algif_aead disabled, though. Does anyone know?"
According to my research, it isn't used on most systems.
"Disabling algif_aead typically does not break anything, as most programs use userspace libraries instead of relying on this kernel module. It is noted that only a few specific applications, like iwd and cryptsetup with certain non-default algorithms, may be affected."
earliest kernel containing this vulnerability (Score:1)
Does anyone know the earliest kernel version which contains this vulnerability? I am running Ubuntu 22.04 on my laptop, and I cannot find any kernel updates that address this. I am wondering if the kernel which I am running simply predates this flaw introduction.
Re: (Score:2)
Ubuntu sucks is why.
Re: (Score:2)
Somewhere I had read the initial optimization that lead to this vulnerability was entered into the mainline kernel in 2017, maybe that will give you something to go on.
Re: earliest kernel containing this vulnerability (Score:2)
Discovered With AI (Score:3)
AI is getting out of control (Score:2)
The original article was written with AI and it shows.
Finally! Thank you. (Score:2)
A way to become root on my single-user home Linux Mint system w/o having to use sudo. :-)