Birbla

Discussion summary

A security vulnerability was discovered affecting Linux systems, particularly those with outdated software, with patches released in early April. Some users discuss workarounds and the impact on critical systems, while others criticize the security community's response.

What the discussion says

  • The vulnerability affects Linux systems, especially outdated ones.
  • Patches were released on April 1st, addressing the issue.
  • Some users seek workarounds and report on affected distributions.
  • Criticism of the security response and domain registration practices.
“It's extremely serious and affects critical systems.”
— pixel_popping
“Workarounds are available, see https://copy.fail/#mitigation.”
— a96

Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

Sign in
  • Hacker News
  • The page itself seems vibecoded and a bit of an advertisement, but it does look like the vulnerability is real and high risk. It does explain the big security update I just got, guess I'll prioritize updating today.
    by phreack
  • Good thing nobody is silly enough to let fully autonomous AI agents run as regular users on these affected operating systems. That could be disastrous given a zero day prompt injection technique.
    by jesse_dot_id
  • LPE = local privilege escalation

    Too many darn acronyms. This one wasn't too hard to figure out from context but I wish people would define acronyms before using them!

    by hackernudes
  • This submission is currently the main HN submission.

    As of now the submission title is simply “Copy Fail”.

    Given the severity of the exploit, can we edit the Title to add some context that it’s a major Linux vulnerability?

    Eg the other submissions say this : “Copy Fail: 732 Bytes to Root on Every Major Linux Distribution.”

    by jeffwass
  • It's unfortunate that this does not include which versions of the kernel are vulnerable/patched, especially since this is a builtin module which cannot be easily removed with rmmod...

    I was wondering if I was vulnerable running Fedora 44, kernel 6.19.14, and after a few minutes of digging I was able to find the linux-cve-announce mailing list post: https://lore.kernel.org/linux-cve-announce/2026042214-CVE-20... which says:

      ...fixed in 6.18.22 with commit fafe0fa2995a0f7073c1c358d7d3145bcc9aedd8

  ...fixed in 6.19.12 with commit ce42ee423e58dffa5ec03524054c9d8bfd4f6237

  ...fixed in 7.0 with commit a664bf3d603dc3bdcf9ae47cc21e0daec706d7a5
    Hope that helps.
    by arcfour
  • If you want to use the suggested mitigation (disabling kernel module `algif_aead` with a modprobe config), and you do not want to run that whole obfuscated shell code to get an actual root shell, but only check if the module can be loaded, here is a readable version of its first few lines:

        python3 -c 'import socket; s = socket.socket(socket.AF_ALG, socket.SOCK_SEQPACKET, 0); s.bind(("aead","authencesn(hmac(sha256),cbc(aes))")); print("algif_aead probably successfully loaded, mitigation not effective; remove again with: rmmod algif_aead")'
    Similarly, when the mitigation is in place,

        modprobe algif_aead
    should fail with an error.
    by nh2
  • It seems there was some kind of confusion during the disclosure process, because the vendors aren't treating this vulnerability as serious and it remains unpatched in many distros.

    https://access.redhat.com/security/cve/cve-2026-31431 "Moderate severity", "Fix deferred"

    https://security-tracker.debian.org/tracker/CVE-2026-31431

    https://ubuntu.com/security/CVE-2026-31431

    https://www.suse.com/security/cve/CVE-2026-31431.html

    by xeeeeeeeeeeenu
  • As someone who works on the Linux kernel's cryptography code, the regularly occurring AF_ALG exploits are really frustrating. AF_ALG, which was added to the kernel many years ago without sufficient review, should not exist. It's very complex, and it exposes a massive attack surface to unprivileged userspace programs. And it's almost completely unnecessary, as userspace already has its own cryptography code to use. The kernel's cryptography code is just for in-kernel users (for example, dm-crypt).

    The algorithm being used in this exploit, "authencesn", is even an IPsec implementation detail, which never should have been exposed to userspace as a general-purpose en/decryption API.

    If you're in charge of the configuration for a Linux kernel, I strongly recommend disabling all CONFIG_CRYPTO_USER_API_* kconfig options. This would have made this bug, and also every past and future AF_ALG bug, unexploitable. In the unlikely event that you find that it breaks any userspace programs on your system, please help migrate them to userspace crypto code! For some it's already been done. But in general, AF_ALG has actually never been used much in the first place, other than in exploits.

    I don't think there's much other option. This sort of userspace API might have been sort of okay many years ago. But it just doesn't stand up in a world with syzbot, LLM-assisted bug discovery, etc.

    by ebiggers

Explore Birbla archives