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. ```
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.
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.
Imposing requirements on the reporter? No.
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.
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.
Linus is the reason why kernel team doesn't talk to distros. For them bugs are bugs, security related or not.
https://lkml.iu.edu/hypermail/linux/kernel/1711.2/01701.html...
I don't agree with the premise, but I do think it's a sincerely held one.
These are smart people. If it wasn't about their own project I really think they'd have a different point of view. I wonder what they say about Microsoft's security bugs for example!
Literally never. Why would he? He's surrounded by sycophants. And we have Greg for whenever Linus isn't involved anymore, and Greg is just as boneheaded.
Everyone involved here failed to do the right thing, and hiding behind the lack of written words is weak sauce.
A security researcher's ethical obligations are to protect users over vendors (barring any contractual agreement in place). From what has been discussed in this thread, they meet that bar.
Sure, they could have gone the extra mile to ensure the distros were in a good place to patch before they published the exploit. That's a kindness you can wish for, but don't disparage them for not going that extra mile. It's a bonus.
It's also possible that it simply didn't occur to them to do so this time. There's certainly lessons to be learned either way. I don't know that the right lessons will emerge from hostility.
and this is the problem. It used to be the case that if you were smart enough to find an exploit you were also smart enough to realise what would happen if you irresponsibly disclosed it. I guess these tools have made that pattern no longer apply.
The skills to detect code exploits is not the same as the skills to navigate an informal org chart to the satisfaction of an amorphous audience if end users (i.e. us on HN).
That said… as they are a company that supposedly specializes in this field, and is trying to sell a product, I do believe they should do better. Right now, I don’t have much confidence in their product.
I see this as an organizational failure of the Linux ecosystem. There should be better communication between distro and kernel development.
yes, because 30 days had passed from the time the patch landed in the kernel, as per industry standard.
approximately every security researcher, including the likes of google and other big names you may know, does a 90+30 disclosure, which is what happened here. they do this for good reason, which has been figured out over decades of experience in reporting thousands and thousands of vulnerabilities.
the only security researchers i know of that dont like 90+30 actually argue for shorter timelines (or immediate disclosures).
Is this just down to luck, a quirk in the timing about when Linus merged the fix versus when the release gets cut?
wait, what?
you are in another comment thread, of this very post, calling these reporters bumbling and incompetent for their disclosure. "merely bumblingly incompetent and overly eager to get their marketing pitch out the door" - that is your quote.
you also said "Basic care would involve making sure the patches had made it into the wild before ending the embargo", which is the literal opposite of immediate disclosure.
but now you are saying they should have just dropped it with no reporting at all? because that is what "immediate disclosure" means. pop up the exploit script on twitter and call it done.
If you're going wait a month between landing the patch (possibly notifying attackers), but not notify the people who may get the patch to users, it seems like something was mishandled.
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.
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.