Get the top HN stories in your inbox every day.
xeeeeeeeeeeenu
For 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.
john_strinlai
i 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.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.
fresh_broccoli
>the reporter should not be the one responsible for reporting separately to every single downstream of the thing they found a vuln in.
Not "separately to every single downstream", there is the "linux-distros" mailing list for disclosures: https://oss-security.openwall.org/wiki/mailing-lists/distros
This random blogpost from 2022 serves as a proof that disclosing kernel vulnerabilities to the distros list is a well-known practice: https://sam4k.com/a-dummys-guide-to-disclosing-linux-kernel-...
I agree it's a shame that the process isn't more streamlined and the kernel developers aren't forwarding the reports to the distros list.
tptacek
It is literally not the vulnerability researcher's problem to solve or address this.
troad
Why is it the job of the kernel to notify the distros? Why isn't it the job of the distros to keep up on upstream security disclosures?
Expecting a FOSS project to go track down all of its (millions of?) users seems like a very unreasonable expectation, and is well outside of their scope of responsibility.
People have gotten so used to the Github flavour of free-labour, social-network-style FOSS that they've forgotten what all those LICENSE files actually say, which is to make it explicitly clear that the devs are not responsible to you for your issues, up to and including the software setting your house on fire. If you don't like it, you don't have to use it.
steve1977
> a notification should have gone out from the kernel team to a curated list of distro security folk
Who would curate that list though? You don't need permission from the kernel team to spin up a new distro. I can go and create fork of Debian or Arch or whatever today and the kernel team would never know (and neither should they).
This is completely in the responsibility of the distros. If you don't like this model, use something like FreeBSD.
mort96
Sounds like a job for the Linux Foundation maybe?
You don't need anyone's permission to make a distro, that's true, but if you notify Debian, Canonical, Fedora, Red Hat and Arch you're covering a very large fraction of users; way more than today's 0%. In cases like this, perfect is the enemy of the good.
aragilar
Uh, there is a list, named "linux-distros", which is for this purpose (and I think it's for more than just Linux, e.g. I believe it was used for the xz vuln).
Given this was announced when backports weren't ready (and given the POC was at least opaque if not obfuscated), I'm getting the vibe fixing the vuln wasn't as high as a priority as making a media splash.
jamespo
The impacted user count of your debian fork with custom compiled kernel would probably not be more than 1 however.
staticassertion
> they are in a much better position to coordinate and communicate with the maintainers than random reporters are.
They openly refuse to do this and have been given authority by MITRE to work against any such process.
john_strinlai
right, which is why it is confusing that the animosity is aimed at the reporters rather than the kernel security team.
josefx
What process? Wasn't the default state of things to just let any random person of the street spam vulnerability reports without validation or quality control?
undefined
Denvercoder9
Two things can be true simultaneously: the Linux kernel ecosystem should have done better at communicating this to their downstreams, and publicly sharing the exploit was irresponsible.
It is not the responsibility of the initial reporter to communicate to distributions, but the fact that those responsible failed to do that, doesn't give everybody else a free pass.
da_chicken
No, this was already timed disclosure. This is very common and widely accepted. 90+30 is what Google Project Zero uses, for example. The security researcher has met their ethical requirements already. This is entirely on the kernel's security team for failure to communicate downstream. That is their responsibility.
The thing is, malicous actors are already monitoring most major projects and doing either source analysis or binary analysis to figure out if changes were made to patch a vulnerability. So, as soon as you actually patch, you really need to disclose because all you're doing by not disclosing the vulnerability is handing the bad actors a free go. The black hats already know. You need to tell the white hats, too, so they can patch.
john_strinlai
>publicly sharing the exploit was irresponsible
they did it in the established industry standard way that probably every single security researcher you can think of follows (for good reason, i would add).
whoever did the marketing on "responsible disclosure" was a genius.
tptacek says it much better than me: ""Responsible disclosure" is an Orwellian term cooked up between @Stake and Microsoft and other large vendors to coerce researchers into synchronizing with vendor release schedules."
x4132
so what? we should never disclose anything? this will only result in companies suppressing disclosure and leaving vulnerabilities unpatched.
paulnpace
> the reporter should not be the one responsible for reporting separately to every single downstream of the thing they found a vuln in.
It's 2026. We're more than 30 years into the Linux ecosystem. I don't believe this bullshit for a moment.
Given how trivially users can implement mitigation, distributions could have done _something_ to protect their users prior to publication date. A handful of messages is all that was required, not "every single downstream" - that is a straw man.
The publication of a bug that trivially gains root on an incredible number of Linux installs that was discovered using an A.I. tool prior to any of the "downstreams" implementing a fix is intentional. I speculate the motivation is free promotion of the A.I. tool.
john_strinlai
>distributions could have done _something_ to protect their users prior to publication date.
yeah, distributions could be following the kernel updates more closely and they would have been patched prior to publication. mainline was patched 30 days before publication.
it is not the reporter's responsibility to babysit the linux distributions.
ori_b
If 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
its 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.
zamalek
The 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.
tptacek
I worked at the industry's first commercial vulnerability lab (Secure Networks) in the mid-90s, and many of my friends at the time founded X-Force. Commercial vulnerability research has always been about marketing: marketing pays for the vulnerability research. That doesn't make it any less prosocial.
ramon156
I created an account for xint code, wtf is this UX?
I get put into a read-only dashboard with ZERO info. is this live? is this static? how do I use it? the API button just leads me to a swagger doc.
esseph
Your advertising for them on HN would help them too, I bet.
jasonmp85
Does it? Now that I see their name again in this context they're blacklisted for life.
bathtub365
To be clear, the vulnerability existed in Linux, not in Xint Code. It existed whether this group disclosed it or not. Knowledge of it and exploits may have already been bought and sold among various groups with various motives including crime, terrorism, or cyberwarfare who likely made good money off it if this happened.
In that world, the vulnerability has more value to those who seek to exploit it for their own motives, regardless of the consequences. They hope that no one else stumbles on it and fixes it, preventing them from continuing to use it to do bad things.
In the world where it is disclosed, there is more value in fixing the vulnerability as the maintainer’s reputation is at risk (and potentially monetary loss or legal liability if they are shown to be negligent).
zamalek
Yes, and that's why we have the responsible disclosure protocol. It wasn't correctly followed here.
Lammy
> 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.
BeetleB
So if I found a vulnerability that lets hackers withdraw withdraw all the money in your account without a trail on where the money went, you'd be fine with them disclosing it to the public at the same time as the bank learns about it?
Even when there is no known use case of the attack (other than the security researcher's)?
> The vulnerability exists for me either way, and I'd rather have the chance to know about it and minimize risk
By the time you hear about it, the money could be gone because 1000 hackers heard about it from the researcher before you did.
> than to be surprised by the fix and hope nothing bad happened in that meantime.
Hope is not a good strategy here.
Lammy
Yep, I'd be fine with that. My bank has insurance, and my money would be returned.
tomxor
> Immediate public disclosure is the only choice that isn't irresponsible as far as I'm concerned.
No, it's really not.
High severity vulnerabilities are responsibly handled by quietly neutralising them with subtle patches that do not reveal the vulnerability, waiting for those patches to distribute. Then patching or removing the root cause of the vulnerability (at which point opportunists will start to notice), and finally publicly disclosing it when there are already good mitigations in place.
Example: spectre/meltdowm mitigations.
I've been asked to use this approach myself when reaching out to maintainers. Sometimes it's possible to directly fix the vulnerability as a "side effect" by making a legitimate adjacent change.
efortis
With immediate disclosure the provider can decide to shut down while it is fixed. Or to notify users and make it their decision. Or to be prepared with a diversified infra and switch over to a non-vulnerable path. e.g, BSDs are not affected by CopyFail
eschaton
“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
They're literally just restating the argument for full disclosure security. This is one of the oldest debates in information security.
undefined
akerl_
What the heck is up with people today.
Using quotes around something where you’re actually doing a strawman paraphrase of another commenter you disagree with is bad form.
notsound
Those groups care about whether millions of computers are vulnerable, likely including your computer. If "immediate public disclosure" was done in all cases every vuln would be exploited and patches would be much lower quality. Shortening the disclosure timeline might be a good idea, 90 days is starting to feel long.
Lammy
Millions of computers are still vulnerable. Not-knowing about it doesn't mean the vuln isn't there :p
pphysch
The Venn diagram of mainstream distros and individual Linux users is virtually a circle.
Ubuntu/RHEL is vulnerable and so are most Linux users by extension.
tptacek
Without 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
> 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.
undefined
lifis
The 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-protect...)
dawnerd
A LOT of websites are tenants on WHM/CPanel hosts. Not to mention how many agencies use it for their clients Wordpress sites.
undefined
hsbauauvhabzb
They built it wrong.
morpheuskafka
I 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.
marshray
Unix originated during the early days of what was called "time sharing", but it was developed for relatively small computers typically shared among a small workgroup within an organization. It was not initially designed to be a highly secure system.
This is how you end up with a file called "/etc/passwd" that is required to be world-readable.
anthk
SDF used NetBSD. In the 90's they switched for a while for RH under X86. Worst era ever, very insecure. Now they use NetBSD X86-64.
On Hyperbola GNU/Linux, they will shift into OpenBSD, they got fed up with the corporate slopware (and propietary Linux became). They will still make Hyperbola BSD GNU-license compatible, from core to the userland tools.
In my case, I wish Emacs and GNU developers embraced plotutils and left out Gnuplot (is not GNU at all; worse, it conflicts with the GPL) and made Texinfo independent of LaTeX to produce PDF and HTML files with equations. Groff + troff+pic+eqn already do that, no Texlive needed. So can mandoc under OpenBSD, no magic needed, everything under few MB's.
Texlive it's huge (full instal it's over 7GB) and the so-called free FSDG is not 100% free, at all. With just that GNU Emacs would be truely GNU-standalone, relying on GNU tools for plots under Emacs' Calc and Texinfo books exported into PDF. A good plus for security.
Once you get that working, the rest would just follow their way. Also, GNU Hurd being developed with propietary LLM's/SAAS it's a disgrace against what GNU stands for too. They can go back to the right path, but they need will, for sure.
watermelon0
I'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
In 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.
shimman
Expecting 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.
dwedge
When the exploit is an advertisement for an exploit detection company, not doing the right thing is a bad look
dgellow
The 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
egonschiele
Why 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
Most distros are maintained by commercial companies.
holowoodman
I 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...
staticassertion
The patch was available. Upstream just doesn't communicate vulnerabilities because they have a personal dispute with distros about how to handle patching.
akerl_
> maybe even criminal
What’s your theory here? What crime?
SoftTalker
AIUI the exploit was fairly low-effort once you knew the vulnerability. So publishing one probably didn't change the landscape much.
wang_li
There is an alternative mitigation you can use which blacklists the function calls when the affected code is not built as a kernel module.
semiquaver
Patches were available for nearly a month.
baggy_trough
Why wouldn't the linux security team notify the main linux distributions?
staticassertion
Greg 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.
bonzini
Partly 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).
bluepuma77
Well, how do you define main Linux distros? Isn’t the next smaller one not receiving the info always complaining?
undefined
shimman
Because one of them might have an incentive to not do so. In this case it's because they want to advertise their own company.
skywhopper
I 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
In 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?
bossyTeacher
> expecting people to always do the right thing is fantasy level thinking.
Most people in tech think like the techie in this comic strip.
ebiederm
The 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?
CodesInChaos
> 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
This 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
Modern 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.
semiquaver
> 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…
aduwah
Especially since the reporter is explicitly asked not to notify the distro teams first.
https://docs.kernel.org/process/security-bugs.html
```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. ```
pmontra
There are a zillion of distributions. The mailing list at https://oss-security.openwall.org/wiki/mailing-lists/distros includes some I never heard about and misses some famous ones (Mint, POP OS.)
The bug is in the kernel, so it's OK to notify only the kernel team. Then they should notify the distributions they are in contact with.
The first message about Copy Fail that I see in the archive https://www.openwall.com/lists/oss-security/2026/04/ is from April 29. I run apt on my Debian 13 yesterday and got the fixed kernel.
Do I expect that every distribution is already patched? I don't. However each of us choose the distribution to run. Security can be one of the criteria for the choice. I played safe and I'm using Debian. Other people can make a different tradeoff maybe based on their personal threat analysis.
There are people running end of life kernels and distributions in production, or with pinned old kernels especially on ARM SBCs. I know both. Those are other choices made at the user end of the process.
IMHO the disclosure and fix process was run in the proper way from the researcher to the end user.
nubinetwork
I don't get why the initial reporter should have to do that legwork. The kernel maintainers should be doing that.
nomel
Ffs, we're talking about open source projects here. Those mailing lists, mentioned there, ARE PUBLIC.
Make them private? Now you have a nice stream of zero days, long before fixes are available, making bad actors who made it in filthy rich.
stonogo
The kernel team has been at odds with the CVE process and the oss-security community about this stuff for many, many years now. It's a big part of why the kernel team established a CNA and started flooding CVE notifications; they don't believe that security problems are different than non-security problems, and refuse to establish norms or policies based on the idea that they are.
throw0101a
> […] they don't believe that security problems are different than non-security problems, and refuse to establish norms or policies based on the idea that they are.
They believe there is no difference being able to get root and not being able to get root? It seems to me that to-be(-root) and not-to-be(-root) are quite different.
IshKebab
It's such a bizarre viewpoint. I wonder when Linus will see sense.
IMO it's pretty obviously not a view that they seriously hold, it's just one of those technical justifications people come up with to avoid admitting something they don't want to admit - in this case that Linux has a poor security track record.
ferngodfather
> and you fully understand the requirements that contacting “linux-distros” will impose on you
Imposing requirements on the reporter? No.
sega_sai
The reporter took time to check and mention on their website specific distributions Ubuntu/RHEL/SUSE. One would have thought reporting to security teams of at least those would be responsible.
semiquaver
“One” would have thought? Can you point to a written policy that says that’s how it should be?
happyopossum
No, nor can I point to a written policy that states one should cover one’s mouth when they cough.
Everyone involved here failed to do the right thing, and hiding behind the lack of written words is weak sauce.
anikom15
The tenets of decency don’t need to be written down.
skywhopper
The reporter made a website explicitly calling out Ubuntu, RedHat, Amazon, and SUSE but didn’t notify them, and you think that’s reasonable? That they might not have known those distributions are downstream from the kernel team?
Legend2440
If you notify the kernel and they ship a fix, it seems reasonable to expect that they will communicate the fix to the distros.
I see this as an organizational failure of the Linux ecosystem. There should be better communication between distro and kernel development.
dweinus
The reporter clearly knows the distro fixes have not been shipped, read their report. They chose to disclose anyway.
sigmar
What is the heuristic for who should get the heads up? Should they notify amazon but not google simply because they named amazon linux in the report? Seems to me the answer to my first question gets messy fast.
sparker72678
Sure, 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
No, you're in more pain, but other defenders with different postures benefit from having faster and fuller disclosure.
ori_b
Mind 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.
throw0101a
> No, you're in more pain, but other defenders with different postures benefit from having faster and fuller disclosure.
Good for them. But just because some folks cannot afford 24/7 response teams and on-call personnel that doesn't make them or their systems any less important.
Lots of non-profits and academic institutions had to scramble because of the Linux kernel team's position of non-communication to distros.
froh
it's trivial to find out how to report a security issue like this to Linux distros.
Google search: https://share.google/aimode/eihDKXZJy94Z5lC1p
and it's beyond me to not think about doing this and instead exposing everyone and their neighbor to this exploit up front.
I'm certain this is even a felony in some legislations, rightfully so.
undefined
dboreham
Agree it's not a good look for these folks, notwithstanding that disclosure is mostly theater.
whatevaa
Stop 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.
pamcake
Look, if they namedrop specific distros in their announcement (marketing) blog post as affected, I think a heads-up before publishing that is appropriate and expected.
I don't think they would have gotten as much flame if it weren't for how the RHEL 14 mention and such were put.
This is a security company with a professional(?) communications department banking on pointing fingers at distro maintainers. We are not talking about solo security researchers or academics here.
nirava
Exactly. Any security person absolutely KNOWS that the distros are still going to be vulnerable. They're exploiting this process loophole to knowingly cause chaos and gain notoriety.
At this point this is not really white-hat/ethical hacking anymore.
Ofc the kernel-distro security loophole is stupid and should be patched ASAP, but that doesn't absolve this company of wrongdoing.
systems_glitch
We all know that's what it is, I don't know why people aren't willing to just say it.
It has a domain, it has a logo, they were going for maximum impact because it's their business.
undefined
bcjdjsndon
Linus should take his trademark autistic rage where he calls other peoples code "dogshit" onto his own work for once. He likes the glory of leading the kernel development but not the responsibilitys like this.
dweinus
No, I will. The distros and the kernel devs should be talking and moving on high sev patches, sure. But real people will have gotten hurt because the reporter didn't want to wait for that to happen. That's on them.
john_strinlai
you must be unfamiliar what used to happen before hard deadlines were set on disclosure. it was much worse for the users.
here is a good start: https://projectzero.google/vulnerability-disclosure-faq.html...
there is ~3 decades of more context if you search for it.
stingraycharles
tldr: if security issues don’t get disclosed (or the real threat of disclosure) they won’t get fixed / prioritized.
pkoiralap
It'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.
rcxdude
A 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.
bell-cot
Bashing 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
Great metaphor.
I'd hate to be involved in any emergency services. Too many people have opinions on how things should have been done.
iTokio
The most interesting exchange, related to disclosure, is this one:
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
As much as I like linux, this is stupid.
fguerraz
Distributions 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
Yes.
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.
GranPC
Just 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
I am running this in production right now and it mitigates the attack, with no unexpected side-effects as far as I can see.
sersi
Interesting 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
The 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.)
sersi
Thanks for the reply (and thanks for the work you do)! Fair enough. And the issue is also that without some form of vetting you run the risk of disclosing the 0 day too early?
About that "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.", you mean that if you disclose selectively, then you become liable for damages? or was it a more direct conversation with legal/governmental agencies?
And for a bug like this, what is the policy with backporting patches to lts branches? Since it was corrected in mainline on april 1st but only backported after the public disclosure. Do you delay backporting to minimise any attention on the security issue?
I guess that having a patch for that land on all the LTS branch would signal to any would be attacker that it's a significant security issue...
Sorry for all the questions but I'm genuinely interested.
EDIT: Just read your blog post at http://www.kroah.com/log/blog/2026/01/02/linux-kernel-securi... which does answer a lot of my questions...
skydhash
If 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.
tonyarkles
Oh... thank you for the reminder to try running the C version of this exploit on an Android phone over adb. The curiosity is now killing me.
Edit: for context, I work in embedded and the aarch64 version (PR #42 in the repo) has successfully popped every device I've tried it against except one where I have a custom kernel to work around a driver issue and (looking back at my git logs) accidentally forgot to enable the user-mode API for alg_aead specifically. Lucky mistake.
hnfong
Just a wild guess:
Given the potential impact a severe security issue in the kernel (like this one), it seems that the only process that is acceptable for government agencies of various countries (that deal with intelligence and national security) is to either keep secrets from everyone, or disclose them to everyone.
Otherwise, the entities on the priority disclosure list would basically have free access to zero day vulnerabilities. Then every country with a national intelligence agency would invent a distro and try to squeeze themselves onto that list, and things would become very political and ugly if the agents of any country can't get into that list...
KingMachiavelli
`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.
muvlon
While I hate suid as much as the next person, it's really not the problem here.
The bug that is being exploited gives you basically arbitrary page cache poisoning. At that point it's already game over. Patching a suid program is maybe the easiest way to get a root shell from that but far from the only.
xorcist
The proof of concept exploit is just that. It is meant to demonstrate one attack vector only. There are many others. If your goal is to prevent the conceptual exploit only then there are many easier ways to accomplish that, such as blacklisting, that does not make you safer.
With this vulnerability you can manipulate the page cache. You could also manipulate ld.so to hook into arbitraty system calls, or set your uid to 0, or any of another dozen or so ways to elevate your privileges.
Mount points have nothing to do with this, even if is always a good idea to disallow suid in user writable areas and prevent reading suid files, but that's for other reasons. NixOS does nothing to fix this and is just as vulnerable as everyone else.
akdev1l
Without 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)
aaronmdjones
> 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)
akdev1l
interesting but in that case no point in keeping the x bit either and suid binaries should just be 4700 ?
tryauuum
this ld.so magic will lose the suid bit
$ /bin/ld.so `which sudo`
sudo-rs: sudo must be owned by uid 0 and have the setuid bit setPlagman
loader
ectospheno
The Bleeping Computer link below mentions a potential remedy until a patch is ready.
https://www.bleepingcomputer.com/news/security/new-linux-cop...
jayofdoom
This 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
There 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...
https://github.com/theori-io/copy-fail-CVE-2026-31431/issues...
pitrdevries
This worked as a mitigation on distros with the module compiled into the kernel: https://gist.github.com/m3nu/c19269ef4fd6fa53b03eb388f77464d...
Basically: sudo grubby --update-kernel=ALL --args=initcall_blacklist=algif_aead_init
sudo reboot
akdev1l
F44 is safe as the kernel is greater than 6.18.22
ranger_danger
For 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.
holowoodman
The potential remedy doesn't work on RedHat and derivatives because the affected code is not a module there but statically compiled in.
lokar
I 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
Nonsense 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
That’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.
foreman_
The Linux kernel security team has chosen not to operate a coordinated downstream notification process. That’s a defensible choice at this scale, but it has a consequence: the kernel is a low-coordination upstream by design. Distros that ship it carry the cost. They track the commit stream, pay a vendor that does (RHEL, Ubuntu Pro), or accept the latency. Different points on a cost curve, not different levels of competence.
The researcher’s job is to surface information. The kernel team’s job, in this architecture, is to patch. The distros’ job is to track. The operator’s job is to pick a distro whose tracking matches the threat model.
When a 30-day disclosure catches you out, the question isn’t who failed. It’s which point on the cost curve your distro choice put you on, and whether that was the point you thought you were on.
swinglock
Neither was NixOS.
https://discourse.nixos.org/t/is-nixos-affected-by-copy-fail...
Denvercoder9
None of the distros were.
samagragune
A 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
Get the top HN stories in your inbox every day.
Recent: Copy Fail - https://news.ycombinator.com/item?id=47952181 - April 2026 (466 comments)