US Government Warns of Severe CopyFail Bug Affecting Major Versions of Linux (techcrunch.com)
- Reference: 0183132574
- News link: https://linux.slashdot.org/story/26/05/05/1535209/us-government-warns-of-severe-copyfail-bug-affecting-major-versions-of-linux
- Source link: https://techcrunch.com/2026/05/04/u-s-government-warns-of-severe-copyfail-bug-affecting-major-versions-of-linux/
> A severe security vulnerability [1]affecting almost every version of the Linux operating system has caught defenders off-guard and scrambling to patch after security researchers publicly released exploit code that allows attackers to take complete control of vulnerable systems. The U.S. government [2]says the bug, dubbed "CopyFail," is [3]now being exploited in the wild , meaning it's being actively used in malicious hacking campaigns. [...] Given the risk to the federal enterprise network, U.S. cybersecurity agency CISA has [4]ordered all civilian federal agencies to patch any affected systems by May 15.
[1] https://it.slashdot.org/story/26/04/30/207231/new-linux-copy-fail-vulnerability-enables-root-access-on-major-distros
[2] https://www.cisa.gov/known-exploited-vulnerabilities-catalog?search=31431&field_date_added_wrapper=all&field_cve=&sort_by=field_date_added&items_per_page=20&url=
[3] https://techcrunch.com/2026/05/04/u-s-government-warns-of-severe-copyfail-bug-affecting-major-versions-of-linux/
[4] https://www.cisa.gov/news-events/alerts/2026/05/01/cisa-adds-one-known-exploited-vulnerability-catalog
15 years or so of coverage. Pretty nasty. (Score:2)
Exploits in Python and other langs. Check [1]https://copy.fail/ [copy.fail] to try the snippet on your server. The easiest workaround is to remove/blacklist the LKM called algif_aead.
[1] https://copy.fail/
Nothing before late 2017 was impacted. LPE only. (Score:1)
Also, it's a bit of a lie to say it affects all version of Linux. It's been absolutely absent on systems made in the middle of 2017 or before. I know most of the children around here consider 9 years to be "all versions" but to me that's laughable (started with SLS Linux in 1993). It's not even close to "all". Now if you'd have said "almost every modern version" I would be forced to agree. However, I work with mostly old systems and haven't had much trouble with this. It's also, so far, only a LPE, not an R
Re: (Score:3)
> I know most of the children around here consider 9 years to be "all versions" but to me that's laughable
There are two dangerous people in the world: newbies, and experts. The newbies don't know what they are talking about, and the experts are so certain they are blind to the reality of the world around them. We are talking security here. 9 years may not be "old" for your pet project, but in the world of production systems 9 years already covers every major version of Linux currently under support without paying for an expensive maintenance agreement, and that includes LTS releases. This includes every current
Re: Nothing before late 2017 was impacted. LPE onl (Score:2)
9 years isnt a long time for anyone except kids and Gen Z. There are probably a shitload of embedded systems with kernels older than 9 years and probably some old phones and tablets still around too. Sure, for external facing systems you need to be up to date, but plenty of corps dont upgrade the firewalled backend servers for a long period because they Just Work and new kernel can mean new bugs and new failure scenarios not to mention app compatibility issues. See: Cobol.
So get off your high horse sonny an
Re: Nothing before late 2017 was impacted. LPE onl (Score:2)
9 years isnt a long time for anyone except kids. There are probably a shitload of embedded systems with kernels older than 9 years and probably some old phones and tablets still around too. Sure, for external facing systems you need to be up to date, but plenty of corps dont upgrade the firewalled backend servers for a long period because they Just Work and new kernel can mean new bugs and new failure scenarios not to mention app compatibility issues. See: Cobol.
So get off your high horse sonny and when you
Re: (Score:1)
> If you want to split hairs then sure, call it modern Linux
I did, but you "but sekuritee!!" folks were bound to get unglued anyway, because someone brought up something older (you did, in fact). I've noticed you're one of those people who seems to hate the idea that someone runs an old system somewhere for any reason. So, I'll mention that I know someone who runs an IRIX 6.5.30 system on the open Internet and has done so for the last 20+ years and never been hacked or compromised once, despite folks like you screaming bloody murder about how "insecure" that is. Of
Re: (Score:2)
> Also, it's a bit of a lie to say it affects all version of Linux. ...
Agreed. I don't have the module loaded on any of the systems I've tested (about a dozen), and the exploit doesn't run either. This includes some recent and older Devuan systems, and some Ubuntu 24.04 servers.
It would be helpful if the proof of concept exploit had just a bit more to it. For example, it could print something saying you're not vulnerable to this exploit when it fails to open the socket, rather than a cryptic error. Slashdot won't let me paste what I get, mostly because the source code was obfu
Bias: Expect the current regime (Score:3)
to publicize Linux security breaches more vigorously then IOS or Microsoft security breaches. Closed source OS providers have historically had more vulnerabilities, but the US government tends to look the other way.
Why would they do this?
They want closed source solutions to be adopted over open source solutions.
The future the government wants is to ensure each user of a personal computer can be ID'd and tracked. Age verification is the wedge to force this onto every PC. Open source operating systems get in the way of this.
Re: (Score:2)
It's kind of a lame exploit, as it requires the attacker to already have console access on the box.
In most cases, if someone who doesn't work for your company already has that level of access, you already screwed up somewhere in your security stack.
Re: (Score:1)
It's an LPE, but it doesn't require the actual console. It just requires that you have access to a shell account one way or another. That could be SSH, Telnet, VNC, etc...
or a crappy wordpress plugin (Score:2)
Or other crappy web application.
Re: (Score:2)
Cpanel?
[1]https://www.malwarebytes.com/b... [malwarebytes.com]
[1] https://www.malwarebytes.com/blog/news/2026/05/actively-exploited-cpanel-bug-exposes-millions-of-websites-to-takeover
Re: (Score:2)
I would think the main threat is from fooling users into running some downloaded executable code.
Re: (Score:1)
Certainly adds another "attack surface" as they say and could function as a LPE payload for any number of social engineering tricks. Time will tell which ones turn out to be more effective, I suppose. Many Linux users these days are not familiar with the CLI at all, but that still might not mean they cannot be tricked into running a script, download, or email attachment: you're right.
Re: (Score:2)
> In most cases, if someone who doesn't work for your company already has that level of access, you already screwed up somewhere in your security stack.
While true, of course there's still the insider problem to contend with. We've seen plenty of cases where disgruntled employees decide to burn everything on their way out (and, sometimes, not even waiting until then...).
Re: (Score:2)
Yep. Of-course laboratory work-stations often have multiple student users and undergrad coders are like termites. Home single-user Linux systems dodge the bullet & additionally are frequently insured by Dan Wesson.
Re: (Score:2)
> It's kind of a lame exploit, as it requires the attacker to already have console access on the box.
Or an exploit like log4j that gives it to them
Re: (Score:2)
The fuck are you talking about. Literally 4 days ago The US government issued a warning about CVE-2026-32202 - a Windows bug.
There is a bias here, it's your observer bias.
Yep. Keep some older UNSAFE computers. (Score:1)
This is why I keep a few older computers. I fear some scenario where all "unsafe computing devices" are completely banned. I don't know where they will draw the line or what may or may not get grandfathered in, but it's clear that in places like the EU, Russia, Canada, or China, un-bugged non-surveillance-enabled computing is more and more unwelcome. They want control at the software level first, then they appear to want to marry that all the way down to the hardware level (think fingerprint readers and ret
Re: (Score:2)
What hardware in Canada is "unwelcome"?
Re: (Score:1)
I'm not saying that banning hardware that doesn't cooperate with "age" (read: identity) verification is already a thing in Canada or elsewhere. I'm saying that, stepwise, once authoritarians get their way with the software age verification (like Canada is trying right now with Senate Bill S-209) they will likely pivot to wanting hardware features that enforce the ID requirement (and obviously not just Canada).
After watching Canada's naked assault on individual rights the last few years, I'd guess they'd b
Copy Fail: 732 Bytes to Root (Score:2)
[1]Copy Fail: 732 Bytes to Root on Every Major Linux Distribution. [xint.io]
“ [2]Copy Fail [copy.fail] (CVE-2026-31431) is a logic bug in the Linux kernel's authencesn cryptographic template. It lets an unprivileged local user trigger a deterministic, controlled 4-byte write into the page cache of any readable file on the system. A single 732-byte Python script can edit a setuid binary and obtain root on essentially all Linux distributions shipped since 2017.”
[1] https://xint.io/blog/copy-fail-linux-distributions
[2] https://copy.fail/
The government heard this only NOW? (Score:1)
I first hear about copyfail about a week ago and at that time they had detected no exploits in the wild. I patched the next day. In security circles, this is OLD news.
- BTW: there were also mitigations to prevent exploit in case you could not patch already available on day 1 of the announcements. So SOME security people knew earlier and had already taken action.
Several Linux distributions pushed out updates, patches, or early releases to prevent either anxiety or impact among their community.
Thanks guys!
None of my machines has the module loaded. (Score:4, Informative)
You can check (as pages on this say):
grep -qE '^algif_aead ' /proc/modules && echo "Affected module is loaded" || echo "Affected module is NOT loaded"
And none of my machines has that module loaded, happily.
Re:None of my machines has the module loaded. (Score:5, Informative)
It still does if it's not a module, which is true for many Linux distributions that have it compiled-in.
I have tested them and they were vulnerable even though that "grep" command said it was not loaded (because it's not a module in many distros).
Re: None of my machines has the module loaded. (Score:2)
That module can always be added to the blacklist in /etc/modprobe.d/blacklist file
Distrubtions with compiled in module: (Score:4, Informative)
Don't be so self-assured. For the following distributions you can't unload the module as it is compiled in the kernel and would not show up in /proc/modules either. These distributions cover a FUCKING HUGE market share for Linux:
Distributions with algif_aead compiled in (vulnerable as of early May 2026):
Ubuntu: 20.04 LTS, 22.04 LTS, 24.04 LTS.
RHEL-family: Red Hat Enterprise Linux 10.1 (and earlier), AlmaLinux, Rocky Linux, Oracle Linux, CloudLinux.
Amazon Linux: Amazon Linux 2023.
SUSE: SUSE Linux Enterprise 16 and earlier.
Others: Debian (all active releases), Arch Linux, and Fedora.
Embedded: Many Yocto BSPs, NVIDIA Jetson, and Ubuntu Core.
Is yours among them?
Re: (Score:3)
This really points to a couple of things being true.
1) Distributions build too much stuff in and not enough as modules.
2) It's a PITA to build everything as a module, which helps explain 1)
I've built a lot of Linux kernels over the years, fewer in recent ones but still have done it occasionally. And it's the same now as then in that building a kernel which is more modular means running into more gotchas.
Re:Distrubtions with compiled in module: (Score:4, Interesting)
FWIW AlmaLinux didn't wait for Red Hat - they tested their own fixes and have now released new kernels to address this.
[1]https://almalinux.org/blog/202... [almalinux.org]
[1] https://almalinux.org/blog/2026-05-01-cve-2026-31431-copy-fail/?utm_medium=social&utm_source=bluesky
Re: (Score:2)
FYI, seeing the same on Ubuntu server 24.04 - it's built as a module, not loaded by default, and the test exploit fails.
Same for a few versions of Devuan I tested.
IMHO, the copyfail website is doing people a disservice by stating:
> The same 732-byte Python script roots every Linux distribution shipped since 2017.
This may be a far reaching issue, but they're definitely exaggerating.
There should also be a better "am I vulnerable" script. The exploit, if successful, isn't something you want to run (leaves /usr/bin/su effectively hacked). If the exploit fails, it's not clear why (unless you un
Re: (Score:2)
> Is yours among them?
Nope. Plus SELinux, configured properly, completely mitigates the attack.
Re: (Score:1)
You've listed Debian in error here. At least up through current stable, it's a module on x86/x86_64 kernels. I can't speak for their ARM kernels or whatever is in testing/stable, as I haven't tested them recently.
Re: (Score:1)
*I meant to type testing/ un stable there, but I'd be surprised if it was any different. Compiling that shit in statically is a classic RedHat move.