14 ms·
For Linux kernel vulnerabilities, there is no heads-up to distributions
Recent: Copy Fail - https://news.ycombinator.com/item?id=47952181 https://news.ycombinator.com/item?id=47952181 - April 2026 (466 comments)
- xeeeeeeeeeeenu 6mo agoFor context, the author of the linked post, Sam James, is a Gentoo developer. Anyway, this is a disaster. It was extremely irresponsible to share the exploit with the world before the distributions shipped the fix. Who knows how many shared hosting providers were hacked with this. It's also worrying that it seems there's no communication between the kernel security team and distribution maintainers. One would hope that the former would notify the latter, but apparently it's the responsibility of whoever finds the vulnerability.
- shimman 6mo agoExpecting people to do the right thing is a fundamental issue here. Why would you ever expect for all of vulnerabilities to be disclosed privately? There's very little actual incentive to do this. I'm honestly unaware of what systems could be put in place to prevent this but expecting people to always do the right thing is fantasy level thinking. I mean I bet the disclosers thought they were doing the right thing, hence why it's a bad thing to rely on. edit: spelling/grammer.
- baggy_trough 6mo agoWhy wouldn't the linux security team notify the main linux distributions?
- deleted 6mo ago[deleted]
- bonzini 6mo agoPartly they already have enough on their plate. It's up to the reporter to pick how to handle the disclosure, and unless a specific maintainer chooses to handle it, the Linux security team clearly says they won't. Partly they have a strong belief that all kernel bugs are vulnerabilities and all vulnerabilities are just bugs; sometimes taken to the extreme in both ways (on one hand this case where the vulnerability is almost ignored; on the other hand, I saw cases where a VM panic that could be triggered only by a misbehaving host—which could just choose to stop executing the VM—was given a CVE).
- baggy_trough 6mo agoSeems a little crazy. Somebody should evaluate blast radius and do appropriate distro notifications in a case like this (I presume the impact was part of the disclosure, so not much extra work).
- seanhunter 6mo agoYou know the linux kernel is a free software project right? If you think “somebody should” do a thing but you aren’t prepared to do it yourself then you should maybe ask for a full refund.
- baggy_trough 6mo agoThank you very much, seanhunter. You hit the nail on the head there.
- bonzini 6mo agoNot really, because they made Linux a CNA specifically to own the process and distort it the way they want it to be.
- staticassertion 6mo agoThis couldn't be more backwards. This has literally nothing to do with bandwidth. The kernel is a CNA, they are explicitly the ones to do this. The reason they don't is because Linus and Greg have repeatedly, publicly stated that they don't want to because they don't believe that vulnerabilities conceptually make sense for the linux kernel and they refuse to engage in the process.
- bluepuma77 6mo agoWell, how do you define main Linux distros? Isn’t the next smaller one not receiving the info always complaining?
- baggy_trough 6mo agoIsn't there already a distro security list for this purpose?
- staticassertion 6mo agoYes.
- throw0101a 6mo ago> Well, how do you define main Linux distros? Isn’t the next smaller one not receiving the info always complaining? For a first approximation: Ubuntu, Debian, RHEL(-derived) to begin with, and SuSE which is in EU/server space (AIUI): * https://commandlinux.com/statistics/most-popular-linux-distributions-market-share/ https://commandlinux.com/statistics/most-popular-linux-distr... * https://commandlinux.com/statistics/linux-server-market-share/ https://commandlinux.com/statistics/linux-server-market-shar... Seems like Gentoo, Arch, Mint, and Slackware could also be as well: * https://distrowatch.com/dwres.php?resource=major https://distrowatch.com/dwres.php?resource=major U/Deb/RHEL are 'upstream' of a lot of other projects, and fixes would trickle down to Rocky, Alma, etc. Perhaps VM OS in cloud (AWS, Azure) could be a usage gauge as well.
- shimman 6mo agoBecause one of them might have an incentive to not do so. In this case it's because they want to advertise their own company.
- staticassertion 6mo agoGreg and Linus do not believe in the entire concept of "vulnerabilities" in the Linux kernel and do not believe in the methods that distros use like cherry picking, therefor they typically are against issuing CVEs, scoring CVEs, describing vulnerabilities at all (if you use the word "vulnerability", your patch will be rejected), etc. It's fundamentally their position to not work the way that you describe.
- baggy_trough 6mo agoThat doesn't really seem to map onto the situation since Greg himself released a 6.12 with the patch earlier today.
- staticassertion 6mo agoI don't know what you mean at all. I'm just repeating known kernel policy here. What does 6.12 have to do with anything?
- baggy_trough 6mo agoWhat is your interpretation of why Greg KH released a version of 6.12 with this fix in it today, other than to help distributions avoid this vulnerability?
- staticassertion 6mo agoWhy would he ever... not release a new version? I don't get what you're trying to say - I'm stating Greg's explicit policy on the topic. If he did something outside of that policy, that wouldn't change anything.
- baggy_trough 6mo agoIf he doesn't believe in the "concept of vulnerabilities" then it is remarkable that he released a 6.12 targeted on this one fix. Why would he do that otherwise?
- holowoodman 6mo agoI can accept (and welcome) disclosure before there are patches. But publishing a working exploit together with the disclosure before patches are available is really really irresponsible, maybe even criminal. And no, the proposed mitigations don't help with half of the distributions out there...
- semiquaver 6mo agoPatches were available for nearly a month.
- ori_b 6mo agoBasic care would involve making sure the patches had made it into the wild before ending the embargo, and nagging the relevant parties if not. Edit: As of this writing, most distros including Redhat, Fedora, Debian Stable, do not have patches available in the package repos, though they're being actively worked on.
- semiquaver 6mo ago“Made it into the wild?” Patches landed a month ago. Should they also wait until my linksys router from 2018 has a patch ready?
- ori_b 6mo agoPatches are still in the process of landing in most major distros as of the time of this writing. Most users are not able to get an update through their distro's packaging mechanisms.
- SoftTalker 6mo agoIt's a local vulnerability at least. How many people do you let log in to your router? With the way linux is used these days, I'd guess the number of systems with untrusted local users is pretty limited. Even with shared hosting, you generally have root in your VM or container anyway. Unless this enables an escape from that? Still the risk that people who run "curl | bash" without care could get bitten, but usually its "curl | sudo bash" anyway...
- skywhopper 6mo agoI think it’s reasonable to expect folks in the security community who go to the trouble of creating a website detailing security vulnerabilities in specific listed software to pre-notify the security teams of that software. The CopyFail website calls out Ubuntu and Red Hat specifically, but apparently the author of the site did not inform them of the issue? But even if you think making unethical decisions in personal self interest is something no one should be criticized for, surely the Linux kernel team ought to have some process for notifying the top distributions of an upcoming LPE, just out of practicality.
- semiquaver 6mo agoIn what sense do you believe that the reporter did not notify the security team of the relevant software? The vulnerability is in the kernel. Reporter responsibly disclosed using the kernel’s security report mechanism and waited until a patch was ready. Distros are downstream of kernel, that doesn’t entitle them to expect to be contacted directly by every security reporter. That’s not on them. Distros that are big enough should be plugged into the linux security team for notifications. Security researchers cannot be held responsible for broken lines of communication within the org charts of projects that they study. They’re providing a valuable public service already, how much more do you want?
- ragall 6mo ago> that doesn’t entitle them to expect to be contacted directly by the reporter Yes it does. That's how it's always been done and distros can ship a fix well before it ends up in a kernel release.
- michaelmrose 6mo agoIt is suggested that they out of an abundance of caution and 5 or 6 emails. If this is entirely to much to expect we can always help them by mandating that they spend 6 figures annually meeting a much more robust set of requirements that will include notifying all possible affected parties down to Hannah Montana Linux devs if any still exist. Any strategy that assumes that the rest of the world is functional or makes you personally responsible for fixing all of it is equally broken but there is a reasonable middle ground and sending a few more emails lies within it
- dwedge 6mo agoWhen the exploit is an advertisement for an exploit detection company, not doing the right thing is a bad look
- dgellow 6mo agoThe worst thing would be to exploit or sell it for profit. Instead of that, publicizing the exploit is closer to neutral–good in my books, that did trigger a really quick reaction from the different actors to patch their kernels and systems
- ori_b 6mo agoImagine how much quicker the distros would have reacted if they were given a heads up a month ago. But, sure, I guess kudos to this company for not being actively criminal, and merely bumblingly incompetent and overly eager to get their marketing pitch out the door.
- x4132 6mo agoto which distros? how do you ensure fairness? Do you report this to the maintainer of Red Star OS (north korea)? The kernel security team was given the heads up a month ago. At that point it is their decision.
- manquer 6mo agoThere are channels like the distro security mailing list https://oss-security.openwall.org/wiki/mailing-lists/distros https://oss-security.openwall.org/wiki/mailing-lists/distros for this purpose.
- egonschiele 6mo agoWhy don't all these distro maintainers add their own back doors, and mine crypto off our machines without our knowledge? Surely, there is some legal fine print they can add that would let them do that. There is very little incentive for them to maintain these systems, given how thankless and underpaid the work is.
- hsbauauvhabzb 6mo agoMost distros are maintained by commercial companies.
- bossyTeacher 6mo ago> expecting people to always do the right thing is fantasy level thinking. Most people in tech think like the techie in this comic strip. https://xkcd.com/538/ https://xkcd.com/538/
- zamalek 6mo agoThe disclosure was more about marketing than security. From the disclosure page: > Is your software AI-era safe? > Copy Fail was surfaced by Xint Code about an hour of scan time against the Linux crypto/ subsystem. [...] > [Try Xint Code] More chaos makes their product seem even more attractive.
- esseph 6mo agoYour advertising for them on HN would help them too, I bet.
- jasonmp85 6mo agoDoes it? Now that I see their name again in this context they're blacklisted for life.
- CSSer 6mo agoYes, exactly. Name and shame.
- true_religion 6mo agoSame. I did not know who they were, but now they have been named and shamed. Not every publicity is good.
- Scharkenberg 6mo agoIt is the opposite for me. I did not know who they are and now I have a positive opinion of them.
- selectively 6mo agoResearchers are under no obligation to engage in coordinated disclosure and are free to sell 0day for profit. Just fyi. Be glad it was disclosed at all. Be glad a patch was available prior to release.
- 6mo ago
- deng 6mo ago> It was extremely irresponsible to share the exploit with the world before the distributions shipped the fix. Yes, this was clearly a marketing stunt to promote Xint code. I, for one, will never use Xint code and will advise everyone to never use it. To anyone working there: enjoy your 15 minutes, I hope this backfires right in your face.
- deleted 6mo ago[deleted]
- psifertex 6mo agoI doubt it will and I hope it doesn't. External security research happens for one of only a few reasons typically: 1) hobbyists who are learning or just like to do it for fun 2) bug bounties (good luck with those in most open source) 3) marketing for security companies 4) non-public research going to CNO/CNE If you want to kill 3, the output of 1 will not come close to 4 and the public is NOT better off with fewer public bugs.
- akerl_ 6mo agoWho knows how many attackers had found this vulnerability and had already been using it prior to this research finding it?
- Quarrelsome 6mo agowell now everyone does, so the irresponsible disclosure makes it significantly worse.
- akerl_ 6mo agoIt’s your opinion that it’s irresponsible and that it makes something worse.
- Quarrelsome 6mo agoand its your opinion that it doesn't. Shall we continue stating the obvious? We are communicating using glyphs. This language is English. We are on Hacker News. This branch of the conversation is extremely unproductive.
- akerl_ 6mo agoI asked a question and you replied with a statement. Your statement didn’t frame itself as an opinion but as fact. The hilarious bit is that the idea that they needed to coordinate is clearly broken even in just this example. They did give prior notice to the Linux developers, who issued a patch. And they’re still getting raked over the coals in this comment page by armchair quarterbacks who have decided they needed to coordinate with specific distros. If they’d coordinated with those distros, somebody would have a pet distro that didn’t make the cut and they’d be pissed about that. There are risks no matter how they do it, and there will be people who are pissed no matter how they do it. Security researchers don’t owe anybody a specific methodology.
- Quarrelsome 6mo agoyou seemed to suggest with your initial statement that any disclosure was acceptable as people would have been using the exploit prior to the disclosure. I don't think that's a strong argument given now the initial people who were using the exploit prior to disclosure are now joined by people who have learned of the exploit as a consequence of the disclosure happening before all the distribtions were ready. So I feel like the argument reduces into "why is it a problem that now anyone could exploit it, if some people were exploiting it already". Which imho isn't a sensible argument because the issue is clearly the amount of people capable of using the exploit for nefarious purposes, which has increased.
- 999900000999 6mo agoCounterpoint. End users have a right to mitigate this issue on their systems. It is a really really bad look for Linux, puts a bit of water on all hype around switching from Windows.
- jasonmp85 6mo ago[dead]
- roxolotl 6mo agoIt does? The disclosure even says the concern for single user systems is very low. If someone has access to your single user system, remote or otherwise, you’ve already lost on the sort of device people would be switching from windows to Linux on.
- 999900000999 6mo agoSomeone like an AI coding agent perhaps ? This is the type of thing Prompt injection was made for. No OS is perfect. The awkward rollout for this bug fix is proof of that.
- Filligree 6mo agoRoot access does not typically add anything interesting, for a desktop system. All the valuable stuff is already owned by the single user.
- m3047 6mo ago> The disclosure even says the concern for single user systems is very low. For single user systems (not rigorously defined, I presume it's the intersection of our two definitions which we might be talking about) the nature of the exploit is local privilege escalation, of which there could be many possible, and many mitigations / countermeasures against. This could have suddenly appeared from the ether of "unknown unknowns" for some people. Those people farther up the food chain still potentially have service accounts, maybe even user accounts for some purposes, perhaps "trusted" services which deliver them code which they deserialize and run once. (Have a pickle.) severity * impact * likelihood Not everyone looking to migrate from Windows 95 plans to run everything as root afterward. On the copy.fail site: echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.conf rmmod algif_aead 2>/dev/null || true Not everybody needs or wants to wait for their distro, or plans to patch their IC firmware when a config change will do.
- lifis 6mo agoThe Linux kernel is not usable as a security boundary, so anyone who wants to do "shared hosting" and not be hacked needs to use something else, like gVisor or firecracker VMs The only important system that uses it as a security boundary is Android and there is mitigated by the fact that APKs need user approval, plus strict SELinux and seccomp policy plus the GrapheneOS hardening, and in this case the mitigations succeeded (https://discuss.grapheneos.org/d/35110-grapheneos-is-protected-against-copy-fail-and-similar-vulnerabilities-by-selinux https://discuss.grapheneos.org/d/35110-grapheneos-is-protect...)
- dawnerd 6mo agoA LOT of websites are tenants on WHM/CPanel hosts. Not to mention how many agencies use it for their clients Wordpress sites.
- deleted 6mo ago[deleted]
- hsbauauvhabzb 6mo agoThey built it wrong.
- watermelon0 6mo agoI'm quite sure there are many application hosting providers which rely on container runtime such as runC (default runtime of containerd/Docker), and a shared kernel between users.
- staticassertion 6mo agoIn a just world, those companies would be held legally accountable for negligent practices. The Linux kernel upstream has made it clear for decades that security is a dirty word. LPEs on Linux are obscenely commonplace.
- morpheuskafka 6mo agoI thought that was the entire design goal of the Unix model, didn't it originate in the times when hundreds of users logged on to a shared mainframe? There are still public Unix servers like SDF out there. SELinux is just an extra layer so that if someone gets root (ex. due to an exploit in your setuid code or cron jobs etc) it's not game over.
- johnbarron 6mo ago>> Anyway, this is a disaster. It was extremely irresponsible to share the exploit with the world before the distributions shipped the fix. Maybe a decade of corporations with revenue in the billions, paying peanuts and coffee money, for critical vulnerability disclosures made it....
- Lammy 6mo ago> It was extremely irresponsible As a user and admin I disagree. Makes one appreciate what a masterful bit of lexical-engineering “Responsible” Disclosure is, kinda like “Secure” (from me, not forme) Boot — “Responsible” Disclosure is 100% about reputation-management for the various corporation/foundation middleman entities sitting between me and my computer. Those groups don't care that my individual computer is vulnerable but about nobody being able to say “RHEL is vulnerable” or “Ubuntu is vulnerable”. The vulnerability exists for me either way, and I'd rather have the chance to know about it and minimize risk than to be surprised by the fix and hope nothing bad happened in that meantime. Immediate public disclosure is the only choice that isn't irresponsible as far as I'm concerned.
- eschaton 6mo ago“The choice that maximizes potential damage isn’t irresponsible, because it means I can mitigate my own systems immediately.” That’s what you’re saying here.
- tptacek 6mo agoThey're literally just restating the argument for full disclosure security. This is one of the oldest debates in information security.
- 0x0 6mo agoThe disclosure doesn't appear very "full". Looks like this was slipped into mainline linux among dozens of other mostly-irrelevant "CVEs" with nobody highlighting the fact that it is in fact dirty-cow-on-steroids. https://x.com/spendergrsec/status/2049566830771970483 https://x.com/spendergrsec/status/2049566830771970483 https://lore.kernel.org/linux-cve-announce/2026042214-CVE-2026-31431-3d65@gregkh/ https://lore.kernel.org/linux-cve-announce/2026042214-CVE-20... Or is everyone expected to upgrade and reboot every 48 hours for all eternity and just deal with potential regressions all the time? I think this reflects poorly on the original reporters. If you have a weaponized 700-byte universal local root exploit script ready to go, perhaps you should coordinate with major distros for patches to be available before unleashing it on the world. No matter how "veteran" you are.
- tptacek 6mo agoWithout taking a position on the disclosure mechanics: any hosting provider hacked with this was already playing to lose. It is not OK to run competing untrusted tenant workloads under a single shared kernel. Kernel LPEs are not rare. This was a particularly simple and portable one, but the underlying raw capability is a CNE commodity.
- jcalvinowens 6mo ago> Kernel LPEs are not rare. This was a particularly simple and portable one, but the underlying raw capability is a CNE commodity. I absolutely 100% agree with this and I'm glad to see somebody saying it. Any system that is one LPE away from being compromised is already insecure.
- deleted 6mo ago[deleted]
- deleted 6mo ago[deleted]
- mschuster91 6mo ago> Anyway, this is a disaster. It was extremely irresponsible to share the exploit with the world before the distributions shipped the fix. Who knows how many shared hosting providers were hacked with this. Maybe it is irresponsible how little attention we pay to software security. Maybe, software developers of all kind should spend an entire year not developing any features at all, but fix all the tech debt of 30 years instead. Yes, that sounds revolutionary, but I do not see an alternative in an age where all you need to find kernel bugs of this scale with AI agents.
- bombcar 6mo agoThe title on this post was changed to imply that only the Gentoo developer was left out - which I could believe.
- IshKebab 6mo ago> Who knows how many shared hosting providers were hacked with this. None? Because nobody* does hosting using Linux users as a security boundary. It's not the 90s. * Standard HN disclaimer for people that think that some retro shell box with 10 users disproves "nobody": nobody does not literally mean exactly 0 people in this context.
- john_strinlai 6mo agoi have no problem with disclosing a vulnerability 30 days after its patched in the thing you reported to. (in fact, for those unaware, this is the same policy that google's project zero uses: "90+30" https://projectzero.google/vulnerability-disclosure-policy.html https://projectzero.google/vulnerability-disclosure-policy.h...) the real problem is: >It's also worrying that it seems there's no communication between the kernel security team and distribution maintainers. the reporter should not be the one responsible for reporting separately to every single downstream of the thing they found a vuln in. what should be happening, as you allude to, is a communication channel between the kernel security team and distribution maintainers. they are in a much better position to coordinate and communicate with the maintainers than random reporters are. the minute the patch landed in the kernel, a notification should have gone out from the kernel team to a curated list of distro security folk that communicated the importance of the patch, and that the public disclosure would be in 30 days.
- ori_b 6mo agoIf the maintainers were unresponsive, sure -- but it seems slightly hard to buy that a responsible reporter trying to make a big splash and a good impression wouldn't first check "did this make it out to the distros?" before making sysadmin's days real shitty, even if technically they could point fingers at other parties. At which point, if they're paying paying any attention at all to what they reported, they may have realized that a mistake was made.
- john_strinlai 6mo agoits an industry standard disclosure process. 90 days after reporting, or 30 days after the patch lands, the vuln is disclosed. the linux kernel team is in a 10000% better position to communicate to and coordinate their downstreams. it seems completely backwards to me to suggest that the reporter should be responsible for figuring out every possible downstream and opening up separate reports to each of them. the kernel team should have a process/channel to say "this is important! disclosure is in 30 days" that is received by distro security teams. because this is not the first or last time the kernel will have a local privilege escalation. hoping that every reporter, forever in the future, will take the onus on themselves is a recipe for disapointment.
- CodesInChaos 6mo ago> Who knows how many shared hosting providers were hacked with this. I'd consider a shared hoster which allows users to run their own (native) code and doesn't use VMs for tenant isolation extremely irresponsible in 2026.
- saysjonathan 6mo agoThis is probably more common than you think. VMs are expensive, both in resources and cost (if you’re using something commercial). OS-level isolation (shared kernel, cgroups, namespaces) is used pervasively
- CodesInChaos 6mo agoModern VMs, e.g. using Firecracker shouldn't be that expensive. I think it's crazy that Kubernetes doesn't use a VM per pod model, especially since it was started by security conscious google.
- PunchyHamster 6mo agoAt least thankfully workaround is one line in a file.
- ebiederm 6mo agoThe notification happen when the fix was shipped. That people would prefer to been spoon fed only serious security issues is understandable, but not realistic. A large percentage of kernel fixes have the potential to be similarly bad. For some the potential isn't even realized until after the fix has shipped. Ever stable release GregKH says you must upgrade now, because there is something security relevant in there. This happens at least once a week. As for shared hosting providers it is my sense that there is always at least one local privilege escalation available to miscreants. Making shared hosting only safe if there is a certain amount of trust. I remember bugs that were similarly bad from my university days 30+ years ago. Has anything substantially changed?
- TacticalCoder 6mo ago> It was extremely irresponsible to share the exploit with the world before the distributions shipped the fix. It's a total arsehole'y move to not share with open-source projects (like Debian) but for commercial vendors like Microsoft I don't give a crap. Now let's not get carried away either: that's a privilege escalation, so it already requires access to a local account. We're not exactly in Jia Tan "I backdoor every SSH out there if your Linux distro is using systemd" territory either.
- bethekidyouwant 6mo ago“Shared hosting providers” These haven’t been a thing since VMs … basically for this reason. There’s always a local privilege exploit.
- sgbeal 6mo ago> “Shared hosting providers” These haven’t been a thing since VMs That is unfortunately not true. i left my last one only a few years ago and they're still going strong without me.
- bitexploder 6mo agoThere is no such thing as irresponsible disclosure. Thanks though.
- krzyk 6mo agoThere are so many distributions that it is not possible to notify each one, unless there is some single distribution list for all. And if you disclose to just a handful, why ignore the rest?
- porridgeraisin 6mo agoFundamentally. The disclosure is private. Meaning neither the commit messages nor any public info can leak too much information about the bug. It's usually kept rather discrete. It is impractical for the kernel to broadcast to all its users privately. Meaning that either a) distro maintainers should be privy to it, but where does this end?[1] or b) we have the current situation [1] probably the top 5 distros security teams can just be copied into the private mail. Maybe the kernel security private list can forward the emails to them as well. Problem is, every other type of communication between distros and kernel is implicit. In commit messages, patches and release notes. So it's an exceptional case. BTW, with LLMs there's a new issue. It is now cheap to scan the kernel commit log maybe in _next and ask it to identify what could be a patch for a private disclosure. And then immediately RE the patch and exploit it on deployed kernels.
- ExoticPearTree 6mo ago> It was extremely irresponsible to share the exploit with the world before the distributions shipped the fix. I disagree. Exploits should pe published as soon as they are written and found vulnerabilities to have as much details as possible, because if the researchers cannot write an exploit, someone else could. - this has the advantage of forcing upgrades as soon as possible. No more “we need to see and schedule patching” - publishing it as soon as possible makes everyne aware of the threat - it is a learning experience for everyone - “responsible disclosure” was invented by lazy companies that have zero interest in fixing a problem quickly
- franktankbank 6mo ago> but apparently it's the responsibility of whoever finds the vulnerability Aka a white hat professional which should be a prized function richly rewarded. Do you really want these things to be calcified into a government function?
- ectospheno 6mo agoThe Bleeping Computer link below mentions a potential remedy until a patch is ready. https://www.bleepingcomputer.com/news/security/new-linux-copy-fail-flaw-gives-hackers-root-on-major-distros/ https://www.bleepingcomputer.com/news/security/new-linux-cop...
- jayofdoom 6mo agoThis workaround only applies to kernels with the impacted code compiled as a module. RHEL, Fedora, and Gentoo (we use a modified Fedora config) all are configured to build this in directly. Without a patch or config change (as Sam from Gentoo was alluding to), those distributions remain vulnerable.
- jcul 6mo agoThere was some discussion on the GitHub issues about workarounds to disable it, even though it is baked in. https://github.com/theori-io/copy-fail-CVE-2026-31431/issues/30 https://github.com/theori-io/copy-fail-CVE-2026-31431/issues... https://github.com/theori-io/copy-fail-CVE-2026-31431/issues/60 https://github.com/theori-io/copy-fail-CVE-2026-31431/issues...
- pitrdevries 6mo agoThis worked as a mitigation on distros with the module compiled into the kernel: https://gist.github.com/m3nu/c19269ef4fd6fa53b03eb388f77464da https://gist.github.com/m3nu/c19269ef4fd6fa53b03eb388f77464d... Basically: sudo grubby --update-kernel=ALL --args=initcall_blacklist=algif_aead_init sudo reboot
- akdev1l 6mo agoF44 is safe as the kernel is greater than 6.18.22
- ranger_danger 6mo agoFor compiled-in kernels you can also work around it without rebooting via apparmor, seccomp or SELinux at the least, there may be eBPF or other methods too.
- semiquaver 6mo ago> Note that for Linux kernel vulnerabilities, unless the reporter chooses to bring it to the linux-distros ML, there is no heads-up to distributions. Why would they imply it is incumbent on the reporter to liaise with distributions? That seems to assume a high level of familiarity with the linux project. Vulnerability reporters shouldn’t be responsible for directly working with every downstream consumer of the linux kernel, what’s the limiting principal there? Should the reporter also be directly talking to all device manufacturers that use Linux on their machines? IMO reporter did more than enough by responsibly disclosing it to linux and waiting for a patch to land. Aren’t there people in the linux project itself with authority over and responsibility for security vulnerabilities? One would think they would be the ones notifying downstream distros…
- sparker72678 6mo agoSure, maybe it's not a _requirement_, but now we're all in more pain because the reporters are more interested in Fame than Safe Remediation.
- tptacek 6mo agoNo, you're in more pain, but other defenders with different postures benefit from having faster and fuller disclosure.
- ori_b 6mo agoMind explaining how sitting on it a month after the patch landed is 'faster'? To my mind, that's a month where attackers could analyze commit logs, but maintainers are not acting with urgency to ship fixes.
- tptacek 6mo agoNo, I wouldn't, because my own preferences are towards immediate disclosure. Tavis Ormandy dropped Zenbleed out of the sky onto us. It wasn't comfortable, it was a scramble for us, but I don't blame Tavis for it; he made a principled call. Better that people know, than that information be concealed from them while designated elites perform a process.
- uberduper 6mo ago`initcall_blacklist` is a thing.
- ChrisArchitect 6mo agoRelated: Copy Fail https://news.ycombinator.com/item?id=47952181 https://news.ycombinator.com/item?id=47952181
- seniorThrowaway 6mo agoUbuntu has patches out, tested before and after patching.
- GranPC 6mo agoJust for what it's worth, I just pushed an eBPF-based workaround for people who are running kernels in which AF_ALG is linked directly into the kernel and not as a module: https://github.com/Dabbleam/CVE-2026-31431-mitigation https://github.com/Dabbleam/CVE-2026-31431-mitigation I am running this in production right now and it mitigates the attack, with no unexpected side-effects as far as I can see.
- JasonHEIN 6mo agohuh somehow seeing people not using ai to work is like wow moment which i cherish a lot these days
- KingMachiavelli 6mo ago`nosuid` and probably `nodev` should IMO be the default filesystem mount options. `/dev` is already a special devtmpfs and the initrd minimal /dev can just explicitly mount the initrd tmpfs rootfs with `dev` and `suid` if necessary. Letting SUID binaries just "exist" anywhere is a stupendous security issue. What if you mount some external storage medium, how are you to verify that none of the SUID binaries on that block device are malicious. Additionally, this exploit appears to only work if the user executing the SUID binary can also read the SUID binary. There's no reason for non-root users to have read on a SUID binary. NixOS does this correctly. No SUID in the normal package installation directory `/nix/store` and no package leakage outside of that no `nosuid` can safety be used on all other mountpoints. The exception is just a single-purpose `/run/wrappers.$hash` directory that safety contains executable ONLY SUID wrappers.
- akdev1l 6mo agoWithout read permissions you cannot execute the binary, that would not make any sense. To execute the binary it needs to be read from disk and loaded into memory. In fact if you have read permissions but not executable permissions on a specific binary then you can still execute it by calling the linker directly /bin/ld.so.1 /path/to/binary (the linker will read and load the binary and then jump to the entry point without an exec() call)
- Plagman 6mo agoloader
- aaronmdjones 6mo ago> Without read permissions you cannot execute the binary This is not correct, as when the binary is setuid-someone-else, you are not the one executing it; they are. $ cat hello.c #include <stdio.h> int main(void) { (void) puts("Hello, world!"); return 0; } $ clang-21 -Weverything hello.c -o hello $ sudo chown root:root hello $ sudo chmod 4711 hello $ ls -l hello -rws--x--x 1 root root 16056 Apr 30 22:22 hello $ ./hello Hello, world! $ id uid=1000(aaron) gid=1000(aaron) groups=1000(aaron),27(sudo),46(plugdev),100(users) Removing world-readability from all setuid-root binaries on the system would be sufficient to kill the PoC script provided for this vulnerability. It would not be sufficient to prevent exploitation though; there are many ways to abuse the ability to write to files you have read access to in order to gain root, for example by using the vulnerability to alter the cached copy of a file in /etc/sudoers.d/, or overwrite /etc/passwd, or /etc/crontab, ... the list goes on.
- swinglock 6mo agoNeither was NixOS. https://discourse.nixos.org/t/is-nixos-affected-by-copy-fail-edit-yes-it-is/77317 https://discourse.nixos.org/t/is-nixos-affected-by-copy-fail...
- Denvercoder9 6mo agoNone of the distros were.
- VladVladikoff 6mo agoHey Xint Code / tylerni7 <https://news.ycombinator.com/threads?id=tylerni7 https://news.ycombinator.com/threads?id=tylerni7>, maybe you should improve your disclosure process as well? Maybe make it mandatory for users of your tool?
- john_strinlai 6mo agothey disclosed 30 days after the patch was merged in the thing they reported to. its the same disclosure policy as google's project zero, and several other major players, so you should probably be trying to ping a lot more people reporters should not be responsible for finding out and individually reporting to every downstream consumer. blame the kernel security team, who is in a much better position to coordinate notifications to individual distro security teams.
- VladVladikoff 6mo agoIn the original thread they admitted multiple times that they rushed it out for marketing reasons.
- john_strinlai 6mo agoas an explanation for the misnumbered redhat version. the disclosure itself followed a normal timeline, which you can view at the bottom of their blog post.
- deleted 6mo ago[deleted]
- tptacek 6mo agoThe security research community would run you out on a rail if you tried to take a successful research product and attach mandatory disclosure norms to it.
- 6mo ago
- whatevaa 6mo agoStop blaming the reporter. Start asking kernel to fix their process. Linux kernel is no longer a toy project, it has full time employees employed by various companies. They should have handled notifying distributions. Not some rando.
- deleted 6mo ago[deleted]
- pkoiralap 6mo agoIt's one thing to report a vulnerability, another entirely to make a crazy exploit available for any tom, dick, and harry to take and use. It was irresponsible of whoever came up with it to release it in the world without first giving major distros a head's up.
- bell-cot 6mo agoBashing on the reporter is pointless feel-good. This is a massive vuln. It was 4 weeks after Kernel had a patch. They had no way to know if others parties had also discovered the vuln. Lord Knows how many millions of systems could already have been rooted. The reporter is not their minion. If I call 911 to report a fire at an oil storage facility - and they ask me to alert the hospital, then phone the neighboring county's Sheriff Dept., and then...yeah. Either I'm way out in the sticks (and known to/trusted by the 911 operator), or else the 911 service is run by children.
- robocat 6mo agoGreat metaphor. I'd hate to be involved in any emergency services. Too many people have opinions on how things should have been done.
- rcxdude 6mo agoA proof of concept is a very standard thing to include in a disclosure, almost table stakes nowadays because of the amount of bad reports. Once there's any disclosure there will be exploits developed and published anyway, it's not a meaningful difference.
- lrvick 6mo agoWas not disclosed to stagex, and I expect a lot of linux distros. Thankfully we were already on kernel 7.0 so not impacted
- Skywalker13 6mo agoI have checked all the servers (bookworm, bullseye) that I manage, and none of them have the algif_aead module loaded. Seems not fatal to all non-patched systems.
- Denvercoder9 6mo agoNot having the module loaded doesn't mean you're not vulnerable, the kernel loads the module on-demand when it's needed. I tried the exploit on such a system, and it worked. However, not having the module loaded does mean that in normal operation you don't need the module, so the proposed mitigation of disabling the module is safe in the sense that it won't disrupt anything.
- Skywalker13 6mo agoI don't know what exactly can load this module but the servers are running for many weeks and I suppose that if something will load this module, it stays loaded until the next reboot.. no ? I tried to rmmod on all servers and rmmod always returns `ERROR: Module algif_aead is not currently loaded`, that's why I think it's fine. Of course I take a look on https://security-tracker.debian.org/tracker/CVE-2026-31431 https://security-tracker.debian.org/tracker/CVE-2026-31431 for the updates.
- Denvercoder9 6mo ago> I don't know what exactly can load this module Well, for one thing, opening an AF_ALG socket, as the exploit does.
- bombcar 6mo agormmod just tells you it's not loaded; you'd have to delete the module to prevent it auto-loading.
- rcxdude 6mo agothe kernel will autoload modules when they are needed. The fact that the module hasn't been loaded is an indication that the bug may not have been exploited, but it does not mean that you are not vulnerable to it. You need to block the module from loading or remove it entirely to mitigate the issue (which is what the first line of the recommended mitigation states).
- 2OEH8eoCRo0 6mo agoSeems silly. How many distros need to be notified? There are hundreds.
- kro 6mo agoThat is true, but if at least the widely used ones would get notified before that would be beneficial. If they have a responsible security contact point. - Debian - Ubuntu - Arch - Amazon/Azure - Fedora/RHEL
- 2OEH8eoCRo0 6mo agoThen those that aren't notified will complain. I think it's on the distros to follow kernel developments since they are consumers of the kernel, not the other way around. Kernel devs can't possibly know all of the stakeholders that they need to notify.
- iTokio 6mo agoThe most interesting exchange, related to disclosure, is this one: https://www.openwall.com/lists/oss-security/2026/05/01/3 https://www.openwall.com/lists/oss-security/2026/05/01/3 > 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. greg k-h
- whateverboat 6mo agoAs much as I like linux, this is stupid.
- fguerraz 6mo agoDistributions using outdated (sorry “stable”) kernels are stupid. We are not 20 years ago, the world in which it made sense doesn’t exist anymore, but the industry is slow to move on. Just pick a long term release and update it regularly.
- harshreality 6mo agoYes. Distros (point release distros) should use LTS kernels and keep up to date with them. Their "we'll maintain our own kernel branches" model either leads to many missed bugfixes, or duplicates Greg K-H's workload internally, for no practical benefit. If a distro is suspicious of particular patches in the -stable tree, they could maintain a blacklist of them. However, instead of doing that and accruing overhead of possible future merge conflicts, they should hash out their concerns on the -stable mailing list.
- sehansen 5mo agoUnfortunately not all of the LTS kernels were updated with this patch before the public disclosure.
- whateverboat 5mo ago
- worthless-trash 6mo agoI believe this is the side effect of having upstream manage the CVE process. The distros dont get any involvement until release, welcome to the suck.
- Avamander 6mo agoThis is the effect of "every vulnerability is a bug" and "we can't rate the severity of any vulnerabilities". Which very clearly results in "bugfixes" (security patches) not making it everywhere in time because it's just simply ridiculous to ask for each downstream consumer to rate the severity of everything on their own. It's easy to shit on CVEs, some even put out shit CVEs, but at the same time contribute absolutely nothing towards providing a better alternative. It's quite certain that both the Linux project and the Linux CNA needs to take some responsibility and put in some effort at communication and making it easier to triage.
- harshreality 6mo agoThey can't. Linux has too high a profile. Any additional "in group" that had access to embargoed critical security information would have a much higher chance of being compromised. The solution is not to tell more people that patch xxxxxx is a critical security bugfix that needs distros to roll new kernel versions immediately. Major vendors (all the cloud providers) will have security teams that can have the bug mitigated in a few minutes once they're notified. For everyone else... Part of the solution is that distros need to stop believing that their distro kernel branches are any better than linux-stable, and use linux-stable and engage with the linux-stable list and patchsets if they're concerned about what's going into them. Part of the solution is each distro needs a process for pushing critical updates (module blacklists, ebpf patches) to address things like this without forcing all distro users to reboot, which many won't do promptly anyway.
- worthless-trash 5mo agoI used to be work in a group that 'managed' this information a while back. I used to work in redhat product security dealing with embargoed flaws and disclosure dates, it was non trivial to get this process managed. I do think that its the right thing to do, if the reporter is willing to come to the party, but I also understand why if they dont want to. > Part of the solution is each distro needs a process for > pushing critical updates (module blacklists, ebpf patches) > to address things like this without forcing all distro > users to reboot, which many won't do promptly anyway. Almost like a 'mitigation tool' that doesn't require expertise on the users end, but on the providers end.
- anthk 6mo agoHyperbola GNU was save because they still use Python 3.8 for both political and stable reasons.
- m00dy 6mo agoWelcome to AI first world, everything is about fail and repriced.
- sersi 6mo agoInteresting comment by Greg Kroah-Hartman when asked why the kernel team doesn't notify distros directly > 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. I'd be interested in knowing more about that policy... Seems that there should be exceptions for the major distros. Of course, major distros who have contracts with SLA could also pay for someone to be on the kernel security team and get a heads up like that..
- gregkh 6mo agoThe members of the kernel security team are not allowed to tell their employers anything that happens on the security list. They are there as individual members, not as employees. And try to define "major distros" in a way that actually means anything viable. If you just want to count users, then that would only be Android (everything else is a rounding error.) After Android, that would be Yocto, and then Debian. All distros after that are mere fractions of overall users compared to those 3 by number of running systems alone. If you want to count it as "$ spent on Linux" then that cuts out Android and Yocto and Debian as those distros are free, and would focus purely on the tiny installed base of paid Linux systems, and cut everyone else out. So what is a fair way to do this other than "we notify no one, and tell everyone to always update their systems to the latest stable releases that we support." Especially as there is no way for us to determine your use case (i.e. if a specific bug is a vulnerability for you or not.)
- skydhash 6mo agoIf you want to talk about possible exploiting being done. Then Android is out (userland is crippled) and I guess yocto as well (same issue). Not that they can’t be attacked, but because mostly what is there is static. As it’s a privilege escalation attack, that leaves us with anything that is running code by unverified users (vulnerable server software, linux shell services, untrusted software you think you’ve sandboxed with user account,…). That put Debian, Ubuntu, Rhel, Fedora, Arch,… installation as the juicest targets.
- foreman_ 6mo ago[flagged]
- ramon156 6mo agoUnrelated but also a CVE that popped up for ProFTPd: https://www.openwall.com/lists/oss-security/2026/05/01/4 https://www.openwall.com/lists/oss-security/2026/05/01/4 What's interesting is that their website is also down right now. These seem like special-timed DDos attacks so maintainers cannot communicate the issue well.
- walletdrainer 6mo agoI suspect there are very few real setups affected by that proftpd bug. Nobody is ddosing anything to cover it up.
- 1970-01-01 6mo agoWhat's really sad about Copy Fail is that it doesn't seem to work on Android. This is a purely bad situation for Linux.
- samagragune 6mo agoA make-me-root bug sitting in the kernel since 2017 and the LTS branches still don't have a clean backport. That's a long window for anything running 6.12 or older
- Akuehne 6mo ago[dead]
- SubiculumCode 6mo agoIs this one related to CVE-2026-41940, allows bypass in cpanel?
- lokar 6mo agoI don’t see what the fuss is about. Sometimes the reporter will go above and beyond beyond to try to coordinate a broad response, sometimes they won’t No one serious should consider the kernel (on its own) a good security boundary (and basic containers don’t count either).
- sophacles 6mo agoNonsense the kernel owns huge swaths of the IO path. For example: It is responsible for all ethernet and IP layer operations, and handles TCP, etc. (By default, there's ways to move these things into userland, but in 99% of cases, programs open a socket, and exchange buffers with the kernel - the kernel does the rest). You're telling me that the kernel should not be a security boundary against malformed packets? That it's no big deal if some malformed packet can crash a machine, cause remote code execution, or cause the system to perform poorly (all real things that have been possible in most tcp/ip stacks, including linux)? Hell (ip|nf)tables firewalling is a security boundary, and it is implemented in the kernel. If you configure a rule and the kernel code handling that rule has a bug that allows bad traffic - isn't this a case of the kernel literally advertising itself as a security boundary and failing? This is where some genius usually steps in and says "well thats why you use a hardware firewall hurr durr - but those are just boxes running a tcp/ip stack with help from some chips that can assist the operations. Problems there: * The hardware or firmware or even the linux kernel running on such boxes may also have bugs, letting bad traffic through to the hosts/servers. * There are categories of network stack bugs with packets that look like good traffic that can still be exploited on the host's kernel. (Aka defense in depth requires the kernel to be the best security boundary it can be also).
- lokar 6mo agoThat’s mostly true, I really had in mind local exploits At the same time, you should use application layer proxies (eg http) that have little or no privileges in your system, nothing else running, as restricted as possible, etc. don’t expose more general hosts to direct raw IP traffic from the internet.
- GoldenGate67 6mo agoWhoa, what the heck!? When I read the site yesterday, I wondered why they disclosed such a critical but (root access on any shell!!!) without waiting a long while for vulnerable systems to be updated. it’s abhorrent to see that they didn’t even wait for an update to release in the first place.
- psifertex 5mo agoIt's not abhorrent. It's quite common and the correct thing to do here. Them not disclosing doesn't make you safer. The people that want to abuse this could be actively exploiting it shortly after the commit went live. Waiting more time before the blog / marketing release is NOT the help you think it will be. This is a very, very, old debate in the security community, just read the rest of this thread and you'll see plenty of explanation as to why.