Forgot your password?
typodupeerror
Bug Government Linux

US Government Warns of Severe CopyFail Bug Affecting Major Versions of Linux (techcrunch.com) 44

An anonymous reader quotes a report from TechCrunch: A severe security vulnerability 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 says the bug, dubbed "CopyFail," is 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 ordered all civilian federal agencies to patch any affected systems by May 15.

US Government Warns of Severe CopyFail Bug Affecting Major Versions of Linux

Comments Filter:
  • by John Allsup ( 987 ) on Tuesday May 05, 2026 @02:11PM (#66129062) Homepage Journal
    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.
    • by kriston ( 7886 ) on Tuesday May 05, 2026 @02:17PM (#66129074) Homepage Journal

      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).

      • by gweihir ( 88907 )

        Indeed. Which should have been obvious enough and said often enough to state that as well: It can be compiled in. Update your kernel.

        This "use" probably just means it is easier to do than other local privilege escalations (which are really often possible). These are not initial exploits, which matter the most. And if you cannot trust your users, you are screwed anyways.

      • Being more thorough:

        ~ $ modinfo algif_aead
        filename: /lib/modules/.../kernel/crypto/algif_aead.ko.zst
        (so it is a loadable .ko)

        ~ $ grep CONFIG_CRYPTO_USER_API_AEAD /boot/config-$(uname -r)
        CONFIG_CRYPTO_USER_API_AEAD=m
        (so it is configured as a loadable module)

        ~ $ lsmod | grep algif_aead
        (returns nothing, so it is not loaded)
    • That module can always be added to the blacklist in /etc/modprobe.d/blacklist file
    • by thegarbz ( 1787294 ) on Tuesday May 05, 2026 @02:33PM (#66129120)

      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?

      • 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.

      • by 93 Escort Wagon ( 326346 ) on Tuesday May 05, 2026 @02:49PM (#66129150)

        FWIW AlmaLinux didn't wait for Red Hat - they tested their own fixes and have now released new kernels to address this.

        https://almalinux.org/blog/202... [almalinux.org]

      • by Bahbus ( 1180627 )

        Is yours among them?

        Nope. Plus SELinux, configured properly, completely mitigates the attack.

      • 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.

        • *I meant to type testing/unstable there, but I'd be surprised if it was any different. Compiling that shit in statically is a classic RedHat move.

      • by reg ( 5428 )
        Add Proxmox and Talos to that list.
      • How did you determine that it's compiled in in Ubuntu LTS releases? On my system it appears to be a loadable ko that is not loaded. (That is, modinfo points to a file, kernel config indicates it is a module, and lsmod indicates it's not loaded). This is on 2404 LTS.
  • Exploits in Python and other langs. Check https://copy.fail/ [copy.fail] to try the snippet on your server. The easiest workaround is to remove/blacklist the LKM called algif_aead.
    • 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
      • 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

        • 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

        • 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

        • 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

      • by unrtst ( 777550 )

        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

  • by hwstar ( 35834 ) on Tuesday May 05, 2026 @02:21PM (#66129084)

    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.

    • by leonbev ( 111395 )

      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.

      • 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...
      • 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...).

      • 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.
      • by G00F ( 241765 )

        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

      • That's pretty myopic thinking.

        First of all, you're wrong. An attacker does not need "console" access but rather does need some kind of shell or execution ability. Given how sophisticated attacks today are often chains of vulnerabilities, I would not at all be surprised to see cPanel or other web vulnerabilities chained with this. Furthermore, if someone who doesn't work for you already has that level of access (meaning ability to execute a program on a computer), you already screwed up? Ok, and what if a tr

    • 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.

    • 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
      • What hardware in Canada is "unwelcome"?

        • 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
      • It's clear that in places like the EU, Russia, Canada, or China, un-bugged non-surveillance-enabled computing is more and more unwelcome.

        Canada is the home of OpenBSD [openbsd.org], which is not only open source, but was founded largely in response to strong cryptography being classified as a "munition" is the US.

  • by Mirnotoriety ( 10462951 ) on Tuesday May 05, 2026 @02:56PM (#66129162)
    Copy Fail: 732 Bytes to Root on Every Major Linux Distribution. [xint.io]

    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.”
  • 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!

"Catch a wave and you're sitting on top of the world." - The Beach Boys

Working...