New Linux 'Copy Fail' Vulnerability Enables Root Access on Major Distributions
thehackernews.com
CVE-2026-31431 CVSS 7.8 flaw since 2017 enables root via 732-byte exploit, impacting major Linux distributions.

Cybersecurity researchers have disclosed details of a Linux local privilege escalation (LPE) flaw that could allow an unprivileged local user to obtain root.

The high-severity vulnerability tracked as CVE-2026-31431 (CVSS score: 7.8) has been codenamed Copy Fail by Xint.io and Theori.

“An unprivileged local user can write four controlled bytes into the page cache of any readable file on a Linux system, and use that to gain root,” the vulnerability research team at Xint.io and Theori said.

At its core, the vulnerability stems from a logic flaw in the Linux kernel’s cryptographic subsystem, specifically within the algif_aead module. The issue was introduced in a source code commit made in August 2017.

Successful exploitation of the shortcoming could allow a simple 732-byte Python script to edit a setuid binary and obtain root on essentially all Linux distributions shipped since 2017, including Amazon Linux, RHEL, SUSE, and Ubuntu. The Python exploit involves four steps -

  • Open an AF_ALG socket and bind to authencesn(hmac(sha256),cbc(aes))
  • Construct the shellcode payload
  • Trigger the write operation to the kernel’s cached copy of “/usr/bin/su”
  • Call execve(“/usr/bin/su”) to load the injected shellcode and run it as root

While the vulnerability is not remotely exploitable in isolation, a local unprivileged user can get root simply by corrupting the page cache of a setuid binary. The same primitive also has cross-container impacts as the page cache is shared across all processes on a system.

  • snoons@lemmy.caEnglish
    47·
    2 days ago

    I suppose this is why my computer updated when I booted it up yesterday. And then I had to update and reboot. Then after I rebooted I had to logout to install extension updates. Then I I had more updates that required another reboot!

    Big thanks to all the people that patched this so quickly, what a huge batch of updates!

    …I am not complaining, I think it’s pretty cool and a bit funny.

    • illusionist@lemmy.zipEnglish
      2·
      16 hours ago

      In response to your comment, I logged into mine, ran the upgrade and saw that it was already there. Easy automatic updates for the win. Thx fedora

  • Scipitie@lemmy.dbzer0.comEnglish
    371·
    2 days ago

    Though this is a severe exploit, note that you need already user access to the machine to use it.

    Dor like … Everyone here who learns from it cis this need it’s likely a non issue. Still good practice to fix but if you didn’t share your user space this will not be the attack vector you will fall victim to - most likely.

    • bdonvr@thelemmy.clubEnglish
      81·
      2 days ago

      Any one of the programs or docker containers you run has user access. Now any of them could have root access unchecked. You can’t know you haven’t installed an update with malicious code to any one of the hundreds of packages a desktop install has.

    • who@feddit.orgEnglish
      7·
      2 days ago

      If I understand correctly, this could be exploited to escape linux namespaces, which which are the foundation of containers like Flatpak and Docker. Those were never very good security boundaries, but running untrusted code in them is now especially dangerous, until your kernel is patched.

  • ZoteTheMighty@lemmy.zipEnglish
    9·
    2 days ago

    If you don’t have the algo_aead kernel module enabled, are you still vulnerable to this? Any systems don’t show it in lsmod whenever I’ve tried, does that mean most computers are OK?

  • r00ty@kbin.life
    15·
    2 days ago

    Just to note, if you are on an LTS version (which many people running servers will be), it’s likely an upgrade will not solve this. In which case you should check your installed version and if not yet corrected, disable that module. For most people it is not used anyway.

    • exu@feditown.comEnglish
      181·
      2 days ago

      According to comments on Lobsters, the distros weren’t notified prior to publication, so any backports took longer than usual.

          • JackbyDev@programming.devEnglish
            2·
            15 hours ago

            From the email thread

            It’s just that instead of drowning in the CVE/CVSS noise, we need a high-quality signal for CVEs that matter the most. Things that would certainly have been CVEs even prior to Linux CNA setup. They may not score the highest per CVSS, but in many cases - like in this one - your team has the knowledge that an issue is to become high-profile, so a timely direct heads-up to linux-distros would be appreciated. Where by “timely” I mean, say, a week (and never more than 14 days) before planned full public disclosure. We don’t normally like to sit on semi-embargoed issues with public fixes, but we did introduce an exception for “Linux kernel issues concurrently or very recently handled by the Linux kernel security team” specifically to accommodate the way your team works.

            How does this sound to you?

            Nope, sorry, we are NOT allowed to notify anyone about anything “ahead of time” otherwise we will have to tell everyone about everything. That’s the only policy by which all the legal/governmental agencies have agreed to allow us to operate in, so we are stuck with it.

            From the policy

            As such, the kernel security team strongly recommends that as a reporter of a potential security issue you DO NOT contact the “linux-distros” mailing list UNTIL a fix is accepted by the affected code’s maintainers and you have read the distros wiki page above and you fully understand the requirements that contacting “linux-distros” will impose on you and the kernel community. This also means that in general it doesn’t make sense to Cc: both lists at once, except maybe for coordination if and while an accepted fix has not yet been merged. In other words, until a fix is accepted do not Cc: “linux-distros”, and after it’s merged do not Cc: the kernel security team.

            It sounds like what you’re describing and what the email thread are discussing are pretty different. The email thread was asking to know about things prior to disclosure. You seem to be saying that they should have directly notified the distros list when the fix was up instead of just posting the article or whatever on their site. Two very different discussions.