Why isn’t copy.fail patched on some distro versions yet?
Posted by Bonn93@reddit | linux | View on Reddit | 38 comments
Rocky Linux has fixes/releases for 8 and 9, what about 10.1!? Debian trixie also has no fix available yet.
Does it feel weird that these are slower than the stable versions?
My popos desktop has a patch available before servers that are internet facing with trixie or rocky, Alma seem to have been faster.
Kangie@reddit
For the enterprise Linux distros, it takes a while to do the backport and complete stability testing - you don't want to ship a dodgy kernel in the name of security.
Really though the guys who disclosed this were irresponsible at best and incompetent at worst: this should never have been published before backports were available to end users.
bankroll5441@reddit
It seems like they really just wanted attention at the end of the day. Who purchases a domain and creates a website for a CVE?
mogoh@reddit
The more distros you tell, and the more are publishing patches, the sooner the exploit will leak to the public. I think, waiting a month is a reasonable time. Nor sure how ever how communication went.
Kangie@reddit
Distros have a specific mailing list where stuff like this is coordinated. It's not public, and only the security teams for various distros are involved. Someone dun goofed.
SkiFire13@reddit
https://www.openwall.com/lists/oss-security/2026/04/30/10
If I read this correctly this was never posted to that mailing list.
TheRealTJ@reddit
They waited nearly a month after the patch was committed to the main branch... how long were they supposed to wait?
Kangie@reddit
Until it was patched in LTS and backports.
Dangerous-Report8517@reddit
A lot of security disclosures wait a lot longer, particularly when disclosing to a group with a pretty well known deployment pipeline that takes time to propagate to LTS and stable releases due to a complex development lifecycle
maelstrom218@reddit
Still waiting for the NixOS patch on stable. :/
BoardroomStroke@reddit
PSA, if you ran the exploit checker that invokes su via python, make sure your 'su' hasn't been broken. I ended up needing to reinstall util-linux packages to replace it.
nachodude@reddit
Might be wrong, but it's just the in memory image su to be "broken". A reboot (or anything forcing the SO to reload from disk should be enough to fix it.
lbl_ye@reddit
opensuse tumbleweed was patched almost immediately
theredcmdcraft@reddit
Debian is patched. Sid,trixie,bookworm and bullseye. All patched Versions are availible on the Security repo.
Rob4226@reddit
Is it patched on Ubuntu 24.04 yet?
Dangerous-Report8517@reddit
Ubuntu apparently disabled the affected kernel module in a recent patch, so even if the kernel doesn't have the fix itself it should still be mitigated if fully updated.
oisecnet@reddit
The kmod package blacklists it, but if thr module is already loaded that will not mitigate it.
mats_o42@reddit
There is a .111 kernel for 24.04 and it's supposed to be fixed. I haven't verified it though
oisecnet@reddit
.111 fixes it, i tested the poc on it and it is safe
More_Implement1639@reddit
Check Debian security repo.
Dangerous-Report8517@reddit
One thing to be aware of is that some distros are choosing to implement the mitigation first so you might have an unpatched kernel but still be secure, not sure if you've specifically checked for that but worth noting
r2vcap@reddit
That is expected for Rocky. Rocky can only rebuild and ship kernel updates after the corresponding RHEL errata and source packages are available. If you are highly security-sensitive, especially for internet-facing servers, you probably should not depend on Rocky or other EL rebuilds for the fastest possible security response.
Bonn93@reddit (OP)
Alma have patched it already. That’s why I’m curious on the differences.
StarChildEve@reddit
A main draw for Alma is that they explicitly patch in bug and security fixes on their own schedule, which is faster than what RHEL/Rocky do.
Bonn93@reddit (OP)
TIL!
ABotelho23@reddit
AlmaLinux is not 1:1 with RHEL like Rocky Linux is. They can patch things without RHEL doing so.
deltatux@reddit
The fix has been in Debian 13 (Trixie) since Thursday night, patched it as soon as I saw someone mentioned it available... They have since backported the fix to Debian 11 and 12.
ButterflyMundane7187@reddit
If you want professional‑grade patches, pay for your OS. Don’t expect professional‑level support from a hobby project.
aioeu@reddit
Wouldn't have necessarily helped. Red Hat, for instance, has not released an updated kernel for RHEL 8, 9 or 10 yet, as far as I know.
Bonn93@reddit (OP)
Cloud envs were fast. Alma were fast. This is why I’m asking it seems a little odd some are so fast and some are slower than usual.
aioeu@reddit
I can't speak for Red Hat, of course, but it's possible that they don't think it is too important to rush out a fix given that a mitigation is readily available.
I think it's also important to transfer that just because some website says "this is really important!" that doesn't necessarily mean it is that for all users. Even if I were running RHEL, I would still want to evaluate whether the vulnerability is something I care about. On servers that only have reasonably trusted users and software I wouldn't care that much.
aioeu@reddit
The further a distribution kernel diverges from the upstream kernel, the harder it is to backport a fix.
El_Vandragon@reddit
I agree they didn't seem to disclose it properly. I also think they may not have made the severity of the issue known to the kernel team either, as the older LTS kernels didn't get an update until AFTER the exploit was publicly revealed. Only 6.18, 6.19, and 7.0 had the fixes at that time.
aioeu@reddit
I also think that's what nust have happened, since major distributions have people on the kernel security team too.
It's a little sad when conclusively are more interested in publishing a flashy website proclaiming how smart they are than in just getting the fix to users.
Bonn93@reddit (OP)
That would be even weirder if the person who found it worked at red hat and they didn’t have a fix version ready. I get they don’t treat this like a zero day and responsible disclosure etc.
aioeu@reddit
It was not found by somebody in Red Hat ... otherwise that would no doubt have been mentioned on the flashy website. I just said the patch that fixed the vulnerability was authored by a Red Hat employee. They themselves may not have known of the significance of the fix, especially if the Xint people themselves never made it clear.
ctnguy@reddit
The fix for Debian Trixie is in kernel package 6.12.85-1 which was released on Thursday. If you're not getting it, you might not have the trixie-security respository enabled.
Bonn93@reddit (OP)
You’re right and after checking my syncs and updates pulled that in.
LesStrater@reddit
The fix for Debian Trixie is in the security repo.