New Linux 'Copy Fail' Vulnerability Enables Root Access On Major Distros (copy.fail) 74
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:3, Informative)
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:Note that this is a local exploit (Score:5, Insightful)
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:5, Funny)
Re: Note that this is a local exploit (Score:2)
What about environments with shared computers though? Think schools, universities. That's a legitimate usage.
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)
Also vms. I segregate users by vms nowadays, at least group of users belonging to the same entity. There were almost always ways to escalate to root from a local user account dating back to the beginning of linux.
Don't get me wrong here, this one is a giant hole although and it need patching ASAP. I say patches should be readily available in a couple days since it's just a matter of turning the caching off as a quick first step for mitigation. Then, re-think the whole caching problem.
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:Note that this is a local exploit (Score:4, Informative)
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:Note that this is a local exploit (Score:4, Interesting)
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:1)
gweihir is the classic retired loser sitting on /. literally all day talking shit and never doing any real work. Guy is gonna get pwned by a single unrelated npm package in a couple months and act like it's everyone else's fault.
Re: (Score:2)
You are projecting hard. Obviously none of your claims are true in any way. But you sound very much like somebody that got called out and is not desperately trying to deflect the attention.
Re: (Score:2)
For a server system? Yes. If the attacker can log in, you have messed up. Period.
If you really think you can protect a somewhat complex installation against users that can log in, you are delusional.
Re: (Score:2)
Who the hell shares machines in 2026? I won't even touch the shared keyboards/mice connected to the docking stations at work.
If I desperately need a computer for something I'd probably be better off using my phone than someone else's PC...
Re:Note that this is a local exploit (Score:5, 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: Note that this is a local exploit (Score:2)
Why are you even here? Your advice is worth less than nothing.
I've got hundreds of servers to secure with thousand of users and you're over here talking about one machine like your advice isn't literally worthless.
Re: (Score:1)
You are just an asshole that is so full of yourself that you cannot even read. And obviously an incompetent sysadmin that just scrapes by. I have met tons of them and they are always as arrogant as they are stupid. You fit that well.
Re: Note that this is a local exploit (Score:1)
The only guy that yaps all day on /. is you. On every thread. Literally. What percentage of your advice is actually coherent? Your mental illness is showing.
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: (Score:2)
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?
In all fairness privilege escalation vulns are ubiquitous. The execution environment of a general purpose operating system is enormous.
Re:Note that this is a local exploit (Score:5, 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:Note that this is a local exploit (Score:4, Insightful)
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 that are totally safe and built with security in mind *cough* Rust, by getting devs to type things like:
(And in Rust's case, they really really want you to do it that way. *SIGH* FFS Rust people! You have a great idea going but you are RUINING it with this type of thing!)
Anyway, the point is you run arbitrary crap more than you think you do, and even if you didn't, things you rely on do sometimes have problems with them.
You need to patch this one now.
Re: (Score:1)
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?
Re: Note that this is a local exploit (Score:2)
These idiots are a dime a dozen in the industry. They come in to any problem and pretend they are smarter than everyone in the room but it turns out they are just proudly ignorant.
Re: (Score:2)
And in actual reality, you are the problem here. And you are aggressive about it because you are deathly afraid somebody may notice.
Re: Note that this is a local exploit (Score:2)
So might as well spread your cheeks then?
Re: (Score:2)
No. Understand defense in depth. And act accordingly.
Re: (Score:2)
If some attack can steal 'root' from you, why are you logging in as 'root' in the first place?
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)
This isn't correct. Immutability won't save you here.
Re: (Score:1)
Tested it. If it's not the immutability itself, then the ones that are immutable seem to be immune for a different reason. Either way, they're still superior.
Re: And this is why (Score:5, Interesting)
Immutable distros still have writable parts of the disk.
typically the setup is /usr or the base OS image: read-only / atomically updated /etc: often writable or layered /var: writable /home: writable /tmp: writable
containers / flatpaks / app data: writable
and then on top of that you'll still have all of these places where something can put binaries, steal credentials, and hide itself across restarts on your perfect immutable machine /home/ /var/tmp /tmp /var/lib/ /var/cache/ /var/log/
container writable layers
upload directories
SQLite/db files
app config/state
user-level systemd/OpenRC/autostart equivalents
browser/profile dirs
SSH config/keys if permissions allow
and that's just desktop workstations. on the server side you've got whatever http(s) server dejour of the day running threads through whatever fcgi nonsense
and then on a modern corp setup you've got people flying around with claude and codex and therefor npm nonsense flying around everywhere and random node binaries in ps aux compiling random shit
Look it helps and most immutable distros are so eccentric no one bothers to try to exploit them for realsies but don't expect to be safe until you patch your kernel.
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:4, Informative)
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 it with a splice() system call to avoid copying the disk cache page elsewhere. Except that specific kernel module overwrites 4 bytes past the end of its buffer, so if you ask for a 32-byte buffer starting at /usr/bin/su byte 696, you can write bytes 728-731, directly in the system's disk cache. And then you can just keep looping to write any arbitrary string of multiples of 4 bytes into what the kernel considers to be a current copy of the latest data on disk for that file, up to that file's size. It's also not marked as dirty, so it never gets written to disk and only gets evicted with normal disk cache operations.
Now, while the attack only works as long as the targetted executable is in the disk cache, that's not much of a problem in practice, because the disk cache often survives the few microseconds needed to set up the required system calls. And once you finally execute the binary as setuid root, Linux consults the disk cache, finds it has a version already and runs it. But you now have a root shell, all without a single disk write, and can now begin to remount filesystems read-write to establish persistence.
Answering a sibling comment, write-xor-execute (W^X) memory doesn't give any protection here either, because a kernel module is performing the write. Write protection on executable pages is provided by the CPU operating in user mode.
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:3)
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.
Re: (Score:3)
Pretty sure I figured it out. The immutable distros I tested have strict security policies that block the exploit. Which still leads me back to immutable distros are superior, because they all seem to have actual security that most of the Linux ecosystem sorely lacks - like anything that still ships with the god awful shit show that is X11.
Re: (Score:2)
If I tell my local jail broken LLM to work on using this exploit for your specific distro how confident are you that it won't hack it after a few hours of effort?
Asleep at the wheel (Score:4, Informative)
Re: (Score:2)
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:3, Informative)
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:3)
Discovered With AI (Score:5, Interesting)
AI is getting out of control (Score:2)
The original article was written with AI and it shows.
Finally! Thank you. (Score:3)
A way to become root on my single-user home Linux Mint system w/o having to use sudo. :-)
That was fast (Score:3)
Microsoft would have buried this kind of thing.
Apple, too.
Already fixed here. That was easy.
Someone's missing (Score:2)
Surprised that a certain vigorous champion of Linux and MacOS hasn't been here yet to boast that this is far less serious than any and all faults in Windows.
Of course there could be downvoted comments lurking below my threshold but I'm not going to unlock it just to see.
Fixed kernels (Score:2)
This info seems to be relatively hidden to get as summarized form, but since I'm running Gentoo I actually wanted to know what kernel versions are affected...Anyway, here goes. Look for commit 3d14bd48e3a.
First appeared in 4.14.
Fixed in:
7.0+
6.19.12
6.18.22
6.12.85
6.6.137
6.1.170
5.15.204