Major Linux vulnerability - Copy Fail

[gmb42]

Fixed all your systems yet? An ancient but latent Linux vulnerability.

https://securelist.com/tr/copyfail-root-linux/119634/

In case the likes of Karel missed it, this is a 17 year old Linux bug.

[Karel]

You'r late, I already patched all my systems:

Code: [Select]

$ apt show kmod
Package: kmod
Version: 31+20240202-2ubuntu7.2
https://ubuntu.com/blog/copy-fail-vulnerability-fixes-available

[madires]

Fixed in 6.12.85, 6.18.22, 6.19.12 and 7.0. And as explained in many posts you can disable loading the algif_aead module (mosts distributions) or pass a kernel boot parameter to block it when built into the kernal (CONFIG_CRYPTO_USER_API_AEAD=y) as a temporary measure until you got a fixed kernel. CVE-2026-31431 / Copy Fail isn't a critical issue for your typical PC at home.

PS: If you run a custom kernel with CONFIG_CRYPTO_USER_API_AEAD disabled your system isn't affected at all.

[golden_labels]

This post has been delayed due to technical issues on the forum. I am posting it nonetheless to provide references.

The issue is fixed in stable >= 7.x and LTS >= 6.18.22.

References:
lore.kernel.org ... gregkh
tag v7.0-rc7 (commit a664bf3)
tag v6.18.22 (commit fafe0fa)

I do not know of any official announcement, but it seems all other LTS lines also just got a fix:
tag v6.12.85 (commit 8b88d99)
tag v6.6.137 (commit 3115af9)
tag v6.1.170 (commit 961cfa2)
tag v5.15.204 (commit 893d22e)
tag v5.15.204 (commit 19d4310)

[peter-h]

This is quite astounding because anybody with a user login can elevate themselves to root.

But it isn't remotely exploitable. You just can't rely on different privilege levels to be isolated

[voltsandjolts]

You mean like they could have in windows with CVE-2025-24076 or CVE-2025-64669?

[Karel]

Linux is far from perfect. Problem is, the alternatives are worse...

[gmb42]

As always, the longtail needs to be catered for. It will probably be hanging around for a long time.

[Cyclotron]

As always, the longtail needs to be catered for. It will probably be hanging around for a long time.

Insightful and spot on!

This is the big problem with these things; this vulnerability will be a part of attacks for some time.

Linux is front line everywhere, tie this vulnerability with something that lets us get non-privileged access, and you're in. Folks seem to dismiss this because you must have local access to exercise it, but non-privileged user access for remote exploits is far more likely in the wild, and this just gives the attack the next step in escalating access.

[voltsandjolts]

https://blogs.cisco.com/security/the-myth-of-the-long-tail-vulnerability

[Cyclotron]

https://blogs.cisco.com/security/the-myth-of-the-long-tail-vulnerability

The author's observations of attacks for a particular vulnerability show that the attack method will be automated, placed in a library and you'll always see it. Hence, no long tail but a continuous attempt on that vector from now on.  I agree.

There are several issues with comparing the author's points and conclusions to the long tail of vulnerable systems. I'll try to briefly unpack them.

The author correctly states that it costs the attacker nearly nothing to keep the attack vector in the library and check as they continue their work. Therefore, there's not really a long tail of attacks for a vulnerability. They become self-sustaining. These are the statistics of attacks. Not the successful ones.

When I look at vulnerabilities such as those discussed in this thread, they do exhibit a long tail, as the number of systems actually vulnerable will drop and eventually be zero. But we are comparing a graph of systems that are vulnerable to a graph of the number of attacks for a given vulnerability.  The two things are only loosely related, as the one-time existence of one is the reason for the other. But that's about it.

For instance, NIMDA vectors are probably still being tested, but there are nearly enough systems available with the required software to be vulnerable. And this is where I disagree with the author's conflation of the vulnerability's existence with the attack statistics.

[peter-h]

I would think that most competent sysadmins would assume that if you give anyone a login, it may be possible to elevate that to root in some way, perhaps not yet discovered.

[Karel]

I would think that most competent sysadmins would assume that if you give anyone a login, it may be possible to elevate that to root in some way, perhaps not yet discovered.

For windows, yes. For Linux no, think about virtual servers e.g. webhosting.
For personal use and workstations running Linux, it's not a big deal.

[Siwastaja]

I would think that most competent sysadmins would assume that if you give anyone a login, it may be possible to elevate that to root in some way, perhaps not yet discovered.

For windows, yes. For Linux no, think about virtual servers e.g. webhosting.
For personal use and workstations running Linux, it's not a big deal.

Web hosting rarely involves full shell access, and virtual server by definition means additional layer (the virtualization layer) of security. Though, even that layer isn't magical, escalating  into root access of the host machine from the virtualized machine also happens every now and then.

We are discussing a "classic" Unix-y user access here - it's very rare nowadays to find servers where thousands of random users have such access. I remember this being normal when still in university, but even then it was limited to students and employees, so some limit of attack surface.

Maybe in the 1990's the choice was "a full machine in datacenter rented to you" vs. "user access to one big server", but in early 2000's the virtualization started and the main reason is not just security, it's the freedom of your "own machine", with the cost much closer to the "user access" than the "separate machine".

Yes, user access is supposed to be safe. It usually is. Such privilege escalation failures are big news (as demonstrated here) and fixed quickly, another question is how many sysadmins apply the fix.

Fact is, nothing is perfect, accidents happen. In data security specifically, it's often hard to see what is the real attack surface, some of the most discussed attacks (especially complicated crypto side channels) end up being totally useless in real world, while some serious attacks indeed are serious. But the human kind has survived all of them.

[Nominal Animal]

In cases where you have many user accounts on the same server(s) — HPC being a particular example —, Unix privilege separation is just one technical detail.  The most important tools are the legal user account agreements and traceability after-the-fact.  For example, if you ensure system logging is directed/tee'd to an otherwise inaccessible machine (and it includes authorization logging), you can always find out which process gained the extra privileges, and trace it back to the human user.

Also, things like CVE-2026-21988, where sufficiently privileged user within a virtualized container can acquire control over the entire physical machine, do also exist.  Security is never perfect, just one step or tool in the overall solution.  Honeypots, detecting script-based attacks at the outer edge of the network and blocking the related IP addresses for a fixed duration, are easily applied external protections.  Tripwires, write-only logging, and even details like firewalling outgoing connections (as opposed to just incoming connections) work quite well as internal technical protections.  With local human users, human solutions like clear legal agreements with legal repercussions work best.  Trust is powerful.

I've been an University sysadmin for HPC and web servers, and designed a security scheme based on Unix groups (and default umask allowing group read-write access), and a small number of related utilities.  Technically, it relies on basic Unix file access controls.  In truth, it is based on humans being social animals: each file is "owned" by the responsible user account, with the project/conference identified by the group name.  Nothing is anonymous, everything has your and your group's name on it.  This is the key that changes how they treat the item and the security related to it: there is visible honor in behaving respectably.  It works extremely well, because there is social cohesion even on the server.  Just try it yourself: if you engrave your name on your tools, you'll treat them better, simply because they're no longer "anonymous", but yours, your name attached to them.

[Cyclotron]

I would think that most competent sysadmins would assume that if you give anyone a login, it may be possible to elevate that to root in some way, perhaps not yet discovered.

This should be the default thinking and planning for building the security of an environment. Trust shouldn't be inferred once you gain access.

No real user logged into the system is required to use this exploit.

All processes on computers run as some user. Often on Linux, the default for unprivileged users is "nobody." But the name of that user belies the fact that it is still just a user. So let's say that "nobody" is running a web server that is using Python, not uncommon. The attacker only needs to find a vulnerability in that web application to run code, and they're in with root access.

There are so many other vectors, too. Embedding the code to gain root into a supply chain attack, and so on.

The security of applications running on systems is often uncomplicated and insecure due to lazy administration. You can configure an environment to run a web server and significantly limit the blast radius of a successful attack by adjusting deep ACL levels, process containerization, and so on.  This goes back to your, in my view, correct expectations for administrators and security professionals. Assume it's insecure and will be breached. Plan for it.

[SiliconWizard]

I think this security hole was never actually exploited in a decade?

As much as I don't believe in security by obscurity, sometimes I do wonder if making a lot of publicity about a potential exploit, when it has just been discovered, never exploited and there was not enough time to ensure admins had the time to update with the fix on a large scale, is really a good idea? But I don't have a solution to this problem: if a vulnerability is found, you have to make it known at least to all who are concerned, and that's a lot of people. And the "bad guys" would find a way to be in the know anyway. So, this is likely the least problematic way of dealing with it, but again it just makes you ponder.

Just imagine your house locks are broken and need to be replaced, and right when you find it out, and before you had a chance to get them replaced, you post a message on social media to say that your house currently has no working lock, that you're working on it, and you give your address. That's a bit uncomfortable.

[peter-h]

Isn't it true that there is no remote vulnerability here, so just blocking all user logins (unless trusted) should do it?

Probably loads of systems have old logins which haven't been cleared up, but that's another issue. I could login into my univ system for about 5 years after I left (1978).

[Marco]

I remember the days that a local exploit came out every day, now it's a couple weeks. Relying on user privileges for security on Linux is very silly. This is the easiest link in an exploit chain, a link hackers will never have much trouble with, same as container escapes (minus gVisor). So piss easy it hardly deserves mention

Dunno why this one got so much hype. More than the recent cPanel exploit, which is immensely more impactful.

[Marco]

Also, things like CVE-2026-21988, where sufficiently privileged user within a virtualized container can acquire control over the entire physical machine, do also exist. 

The only source for this seems sentinelone. The actual text of the CVE details suggest it's a privilege escalation on the VM host, not a VM escape.

[Siwastaja]

I remember the days that a local exploit came out every day, now it's a couple weeks. Relying on user privileges for security on Linux is very silly. This is the easiest link in an exploit chain

Surely this must be exaggerated? It's just 10 years ago I was on a 20000-user server running IRC client in gnu screen, writing and compiling code etc. just like all those other 20000 users. This concept worked well for decades, replicated thousands of times around the world. Not sure how popular such setup is 2026 though. Now it's suddenly trivial to break as a root in such a system, everybody says, but I see little evidence of that happening. But I don't know - maybe I'm missing something?

[Marco]

They didn't even get a CVE or any publicity, they were simply bugfixes. Most people aren't out to get you, especially before the disaster named bitcoin.

[Nominal Animal]

The only source for this seems sentinelone.

Don't quibble.  Oracle is known for a huge list of CVEs, and I specifically wrote "things like".  Perhaps I should have referenced CVE-2025-41236, CVE-2025-41237, and CVE-2025-41238 instead.

Relying on container isolation, or any one other security tool, is what is silly.  Linux/POSIX privilege separation is a perfectly valid tool, and should not be overlooked.  For example, if WordPress, SMF, etc. internally used multiple POSIX user accounts and groups with privilege separation (so that files created by the scripts are non-executable/non-interpretable, only serveable as content as-is), we'd eliminate 99.9% of all forum and website exploits.  (Attacks would shift to supply side, though, so the overall reduction in attacks would be much less.)

Linux kernel privilege escalations are rare.  I would recommend everyone take a look at e.g. CERT-EU critical vulnerabilities list for 2026, 2025, 2024, and earlier, instead of relying on vague "gut feelings" and "beliefs".

[Marco]

Linux kernel privilege escalations are rare.  I would recommend everyone take a look at e.g. CERT-EU critical vulnerabilities list for 2026, 2025, 2024, and earlier, instead of relying on vague "gut feelings" and "beliefs".

Case in point, all remote. The most infamous LPE of 2025 isn't even on the list, sudo. LPE's aren't considered critical.

[madires]

Over the years sudo had security issues regularly. However, it's not part of the kernel.