Live data from Hacker News

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

openwall.com

401–410 of 578 posts

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

#401

Earlier quoted context omitted.

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 report…

> 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,…

The impacted user count of your debian fork with custom compiled kernel would probably not be more than 1 however.

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

#402

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 th…

“Shared hosting providers” These haven’t been a thing since VMs … basically for this reason. There’s always a local privilege exploit.

> “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.

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

#403
post #175

Earlier quoted context omitted.

Unfortunately this is correct. As a security researcher I set millions in profit on fire for reporting vulns to projects that offer no bounties vs selling to highest bidder. I keep doing it because it is the right thing to do, but I would not blame someone that needs to feed their family making a different choice. We must get public funds to reward ethical disclosure of big impact vulns like this.

Harder and harder to get good policy like what you describe when tech-adjacent people loudly argue for criminal penalties for anything other than coordinated disclosure :(

> criminal penalties

Mostly cover citizens within a very limited set of jurisdictions.

Otherwise there's a chance at extradition.

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

#404
post #362

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

As much as I like linux, this is stupid.

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

#405

Earlier quoted context omitted.

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.

I think it's an extension of the premise that you should just be taking the whole stable tree with all its patches constantly, whether they're labeled as security fixes or not, because you can never really know for sure some bugs weren't security bugs. I don't agree with the premise, but I do think it's a sincerely held one.

I dunno, if you think about it for more than a few seconds you can see the obvious holes in it, like it's definitely true that some bugs are "may allow RCE", but you also can do a LOT better than not even trying. And even if you do say "we're not putting the effort in to backport security fixes" (which is fine), that doesn't entail "security bugs are just bugs".

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!

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

#407
post #388
post #373

Earlier quoted context omitted.

> Others backport what they feel are relevant. But from what I understand they were not given enough information to know if it was relevant or not. The commit message just said it reverted a change from another commit because there was "no benefit". From the patch itself, it is not at all evident that this is a fix for a critical security bug.

> The commit message just said it reverted a change from another commit because there was "no benefit". From the patch itself, it is not at all evident that this is a fix for a critical security bug. If the commit message says it fixes a security bug, then bad actors immediately know there's a possible exploit there. So maybe it's intentional? (not familiar with the policy for this)

Then we’re back to the initial problem. How can you fix and then communicate to downstream about security vulnerabilities without exposing those vulnerabilities in an open source project? If you want to reach all your possible users you have to disclose the vulnerability.

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

#408
post #114

Earlier quoted context omitted.

Microsoft's policy is: "if you contact us with a vulnerability, you automatically agree to the terms of our responsible disclosure policy", which includes waiting 30 days after patch was created, and says nothing about how long that process takes. There is actually no way to give them a friendly heads up, and then do your own thing. The only way not to be bound is by not sending them any notification at all...

> terms of our responsible disclosure policy I couldn't find a public copy of that. The best starting point I found for reporting vulnerabilities was: https://github.com/microsoft/MSRC-Security-Research/security... You can email without agreeing to anything. But for a serious issue Microsoft would obviously try and track down who you are and what jurisdiction you are in.

https://www.microsoft.com/en-us/msrc/bounty-guidelines

> MICROSOFT BOUNTY TERMS & CONDITIONS

> Last updated: July 23, 2025

> The Microsoft Bug Bounty Programs Terms and Conditions ("Terms") cover your participation in the Microsoft Bug Bounty Program (the "Program"). These Terms are between you and Microsoft Corporation ("Microsoft," "us" or "we"). By submitting any vulnerabilities to Microsoft or otherwise participating in the Program in any manner, you accept these Terms.

Who knows if its enforceable.

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

#409
post #395

Earlier quoted context omitted.

I didn't say all distros should be notified, for that exact reason. I listed a handful of major fistros.

Who gets to decide who the lucky few are?

Human beings

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

#410

Earlier quoted context omitted.

> 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-k…

It is literally not the vulnerability researcher's problem to solve or address this.

If they get enough time to build a website with a fancy logo instead, one might however question where their priorities are.
Post reply on HN