this post was submitted on 01 May 2026
87 points (97.8% liked)

Linux

17374 readers
25 users here now

Welcome to c/linux!

Welcome to our thriving Linux community! Whether you're a seasoned Linux enthusiast or just starting your journey, we're excited to have you here. Explore, learn, and collaborate with like-minded individuals who share a passion for open-source software and the endless possibilities it offers. Together, let's dive into the world of Linux and embrace the power of freedom, customization, and innovation. Enjoy your stay and feel free to join the vibrant discussions that await you!

Rules:

  1. Stay on topic: Posts and discussions should be related to Linux, open source software, and related technologies.

  2. Be respectful: Treat fellow community members with respect and courtesy.

  3. Quality over quantity: Share informative and thought-provoking content.

  4. No spam or self-promotion: Avoid excessive self-promotion or spamming.

  5. No NSFW adult content

  6. Follow general lemmy guidelines.

founded 2 years ago
MODERATORS
 

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.

you are viewing a single comment's thread
view the rest of the comments
[–] frongt@lemmy.zip 5 points 4 days ago (1 children)

According to Greg K-H, nobody typically gets notified by the Linux kernel team about anything, so this is not abnormal: https://www.openwall.com/lists/oss-security/2026/05/01/3

Distro maintainers should be monitoring the lists and feeds and making decisions themselves, not expecting spoon-feeding from the kernel team.

[–] exu@feditown.com -1 points 4 days ago (1 children)

Yes, but the researchers should have notified the linux-distros mailing list as well per the published policy. See https://docs.kernel.org/process/security-bugs.html#coordination-with-other-groups

It's unfortunate, but understandable why this didn't happen. Still, the researchers claimed in their blog post that fixes were shipping, apparently without actually checking.

[–] JackbyDev@programming.dev 2 points 3 days ago

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.