The kernel security team was given the heads up a month ago. At that point it is their decision.
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...
What’s your theory here? What crime?
But it’s not the law anywhere I’m aware of today, and I’d not support it becoming a law.
Instead of that, you’d rather make the law compel free individuals to limit their speech, or to hand over their work to big companies privately, so big companies can save money?
That doesn’t sound like a nice future, if it’s even enforceable at all.
Also, all kinds of aiding and abetting.
Copying from the comment I was replying to:
> But publishing a working exploit together with the disclosure before patches are available is really really irresponsible, maybe even criminal
That's besides the point. If people use the official mitigation on https://copy.fail/#mitigation they will not sufficiently protect themselves on mainstream distros like Ubuntu and Debian.
The page also states
> Most major distributions are shipping the fix now.
This text was probably prepared in advance, but this was simply not true at the time of publication.
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.
Considering that the patches have been available for a while, someone surely reversed what they were for and was actually exploiting this in the wild.
In the age of AI, I’d argue that “responsible disclosure” is dead. Arguably even in closed source projects. Just ask Claude to do a diff between the previous version and to see whether anything fixed in there could have had security implications.
We’re not there yet, but very soon the only way to responsibly disclose a vulnerability will be immediately.
Linux kernel is one of the most audited open-source projects ever. I guarantee you that someone did reverse the patch.
> but forgot to tell the distros
Probably an oversight, but irrelevant. The bug was in the linux kernel. It's insane to suggest that they should have notified everyone shipping the linux kernel.
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...
Things like HPC clusters are multiuser & don't entirely trust their users. If they did we wouldn't need users/groups/permissions etc in the first place.
And then there are users running claude-cli and friends who may just find it convenient to use a local root exploit to remove obstacles.
Lots of shared hosters don't use VMs or containers. It's some arbitrary number of people logging in to a shared system, each one with a home directory under /home/THE_USER_NAME. i've had several such hosters over the years (thankfully not right now, though).
So containers don't protect you, only a VM.
How so?
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-distr...
* 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
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.
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).
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.
That's exactly what I wrote: "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".
But there is also a question of bandwidth. If a maintainer asks to bring a specific vulnerability to distros-list, the kernel security people will be reasonable. I did it last March.
https://www.openwall.com/lists/oss-security/2026/05/01/3
(About heads up to distros)
> 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.
https://www.openwall.com/lists/oss-security/2026/03/30/5
You can see my name under "Timeline", I asked kindly for both distros-list and a longer embargo than usual and got them.
I guess Greg is not allowed to notify distros-list, but someone else is?
It's fundamentally their position to not work the way that you describe.
As for the latest patch, Greg is currently being forced to clean up a big fucking mess by external parties. And he's miserable about it.
I'd start with Greg's on words. You can probably find more on it from Spender/grsecurity's blog.
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.
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?
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
> we can always help them by mandating that they spend 6 figures
AWS and GCP are downstream another level. Should the reporter also have worked with them? And their customers? And the customers of their customers?
IMO this whole discussion seems like people are annoyed by the security researchers doing god’s work and wish they didn’t exist or think that they should be fully subservient to the projects and companies they are helping for free. The bugs were there before the researchers revealed them!!
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.
Most people in tech think like the techie in this comic strip.
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.