Live data from Hacker News

For Linux kernel vulnerabilities, there is no heads-up to distributions

openwall.com

531–540 of 578 posts

Re: For Linux kernel vulnerabilities, there is no heads-up to distributions

#531

Earlier quoted context omitted.

> Is that a rule? No, it's commonly followed practice: https://en.wikipedia.org/wiki/Coordinated_vulnerability_disc... I'm all for lighting a fire under the developer's ass, but we live in an imperfect world and the biggest problem that we have is end-users. We may have applied the mitigation on day 0, and updated as soon as the kernel landed in our distro - and if some of us didn't then we've even got savvy users in…

> For reference, the standard is 30 for the developer to fix and 90 for it to land on machines no, the standard is 90 days from notification or 30 days from the patch date, typically whichever is sooner . e.g. > If a vendor patches a security issue 47 days after Project Zero notified > the vendor about the vulnerability, details would be made public on day 77. > If a vendor patches a security issue 83 days after Proj…

That's still extremely different to this in one of the GP comments:

> There is no such thing as "the responsible disclosure protocol".

And yes, I admit I got dragged down to their level and beat myself with a dumb stick in the process.

Re: For Linux kernel vulnerabilities, there is no heads-up to distributions

#532

Earlier quoted context omitted.

> Is that a rule? No, it's commonly followed practice: https://en.wikipedia.org/wiki/Coordinated_vulnerability_disc... I'm all for lighting a fire under the developer's ass, but we live in an imperfect world and the biggest problem that we have is end-users. We may have applied the mitigation on day 0, and updated as soon as the kernel landed in our distro - and if some of us didn't then we've even got savvy users in…

You are strongly implying that keeping the vulnerability secret is following of what you quoted. But that’s the rub. Many of us think the opposite. Not disclosing this would have been the violation.

> You are strongly implying that keeping the vulnerability secret is following of what you quoted.

Please don't put words in my mouth when I have clearly stated the contrary. I used the word "disclosure," that is very different to keeping things secret.

Re: For Linux kernel vulnerabilities, there is no heads-up to distributions

#533
post #307

Earlier quoted context omitted.

I don't get why the initial reporter should have to do that legwork. The kernel maintainers should be doing that.

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 .

If you're suggesting a private disclosure channel, made for all the maintainers of the ~600 actively maintained distributions (including those that pop into existence just to get access to the disclosures), then that would be a point you could make. But, that text above is reasonable, because the mailing lists they're referring to are public.

Open source code process must assume bad actors are involved (because they have been historically, and will be always and forever). So, this isn't some "easy" scenario. Talking to the guy that can fix it first, and assumed the distributions contain bad actors, then disclosing to them once the fix is available, is reasonable, and I don't see an alternative.

I would be interested in seeing what the thoughts are on a proper disclosure cycle, for those 600 distributions. Seems very complex.

Re: For Linux kernel vulnerabilities, there is no heads-up to distributions

#534

Earlier quoted context omitted.

> Is that a rule? No, it's commonly followed practice: https://en.wikipedia.org/wiki/Coordinated_vulnerability_disc... I'm all for lighting a fire under the developer's ass, but we live in an imperfect world and the biggest problem that we have is end-users. We may have applied the mitigation on day 0, and updated as soon as the kernel landed in our distro - and if some of us didn't then we've even got savvy users in…

You're trying to extrapolate on this specific scenario from Wikipedia pages. Have you done any of this work? What have you done when you've reported a vulnerability to an upstream with dozens of downstreams? When your teammates have? You keep talking about "protocols" and "commonly followed practice" and "codes of ethics". Tell us more about the codes, protocols, and practices in your shop. Nobody, for what it's wort…

> possibility into a binding obligation

I never said "binding obligation," that is the first time "binding" has appeared in this discussion and was introduced by you. Once again claiming things I have never said. Doing what you are free to do can still be a shitty thing to do.

I am a bluffing moron who knows nothing, you win.

Re: For Linux kernel vulnerabilities, there is no heads-up to distributions

#535

Earlier quoted context omitted.

You are strongly implying that keeping the vulnerability secret is following of what you quoted. But that’s the rub. Many of us think the opposite. Not disclosing this would have been the violation.

> You are strongly implying that keeping the vulnerability secret is following of what you quoted. Please don't put words in my mouth when I have clearly stated the contrary. I used the word "disclosure," that is very different to keeping things secret.

Coordinating disclosure involves keeping things secret for an amount of time.

Re: For Linux kernel vulnerabilities, there is no heads-up to distributions

#536

Earlier quoted context omitted.

> For reference, the standard is 30 for the developer to fix and 90 for it to land on machines no, the standard is 90 days from notification or 30 days from the patch date, typically whichever is sooner . e.g. > If a vendor patches a security issue 47 days after Project Zero notified > the vendor about the vulnerability, details would be made public on day 77. > If a vendor patches a security issue 83 days after Proj…

That's still extremely different to this in one of the GP comments: > There is no such thing as "the responsible disclosure protocol". And yes, I admit I got dragged down to their level and beat myself with a dumb stick in the process.

There is no such thing as "the responsible disclosure protocol".

Re: For Linux kernel vulnerabilities, there is no heads-up to distributions

#537

Earlier quoted context omitted.

You're trying to extrapolate on this specific scenario from Wikipedia pages. Have you done any of this work? What have you done when you've reported a vulnerability to an upstream with dozens of downstreams? When your teammates have? You keep talking about "protocols" and "commonly followed practice" and "codes of ethics". Tell us more about the codes, protocols, and practices in your shop. Nobody, for what it's wort…

> possibility into a binding obligation I never said "binding obligation," that is the first time "binding" has appeared in this discussion and was introduced by you. Once again claiming things I have never said. Doing what you are free to do can still be a shitty thing to do. I am a bluffing moron who knows nothing, you win.

I didn't call you a moron.

Re: For Linux kernel vulnerabilities, there is no heads-up to distributions

#538

Earlier quoted context omitted.

> For reference, the standard is 30 for the developer to fix and 90 for it to land on machines no, the standard is 90 days from notification or 30 days from the patch date, typically whichever is sooner . e.g. > If a vendor patches a security issue 47 days after Project Zero notified > the vendor about the vulnerability, details would be made public on day 77. > If a vendor patches a security issue 83 days after Proj…

That's still extremely different to this in one of the GP comments: > There is no such thing as "the responsible disclosure protocol". And yes, I admit I got dragged down to their level and beat myself with a dumb stick in the process.

There isn’t such a thing. Coordinated disclosure (sometimes called responsible disclosure by people who want to inject their morals into one available option so as to paint the others as irresponsible) exists. As has been noted, some large groups like Project Zero use 90/+30, but that isn’t a set protocol; it’s a thing some folks picked and others have copied. If a research group announced tomorrow that they were doing a flat 42 days from notification to release, they would still be doing coordinated disclosure.

Re: For Linux kernel vulnerabilities, there is no heads-up to distributions

#539

Earlier quoted context omitted.

They didn’t release anything into the wild. It existed. The irresponsible thing would be letting it keep existing without telling anyone.

You cannot deny that telling the entire world about this vulnerability before it is patched won't cause a lot of abuse that would not have happened otherwise.

AFAICT it was a Linux kernel maintainer who first "told the entire world about the vulnerability" on 2026-03-31: https://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryp...

The CVE was officially announced on 2026-04-22: https://lore.kernel.org/linux-cve-announce/2026042214-CVE-20...

Theori were simply the last team to publicly disclose the vulnerability on 2026-04-29, 37 days after reporting it to the vendor. They were simply more effective at communicating it, and they told you that you were vulnerable. That's why you're mad at them instead of the people who put the bug there in the first place, didn't bring its severity to your attention, and silently sat on the patch.

Re: For Linux kernel vulnerabilities, there is no heads-up to distributions

#540
post #419
post #229

Earlier quoted context omitted.

I find it curious to call someone dropping a weaponized root exploit before major distros or even LTS kernel git branches have patches ready "good guys". This could have been handled with much more grace.

To be fair, once Xint gave the heads up and the kernel team committed a patch, what was Xint supposed to do? Keep asking the kernel security team to backport patches for the LTS kernels? As soon as a patch is committed, the clock starts ticking, the exploit will be discovered by reverse engineering recent commits. The commit was made on April 1st, Xint disclosed it on the 29th. If the Kernel Security team had wanted…

The Linux kernel team back-ported it to 6.18, 6.19, and 7.0 on 2026-04-11 and publicly disclosed the vulnerability via CVE on 2026-04-22.
Post reply on HN