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

Post by leni536 » Thu, Apr 30, 2026, 8:23 PM UTC

SCHiM wrote: post #114

tptacek wrote: post #106

Earlier quoted context omitted.

It is absolutely not true that viable commercial vulnerability labs need to "accept the norms around responsible disclosure". There are no such norms. "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. It was fantastically successful at that, and it's worth pushing back on at every opportu…

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

Post by jcalvinowens » Thu, Apr 30, 2026, 8:25 PM UTC

tptacek wrote: post #93

xeeeeeeeeeeenu wrote: post #2

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…

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.

Post by IshKebab » Thu, Apr 30, 2026, 8:25 PM UTC

xeeeeeeeeeeenu wrote: post #2

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…

Post by john_strinlai » Thu, Apr 30, 2026, 8:26 PM UTC

xeeeeeeeeeeenu wrote: post #2

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…

Post by IshKebab » Thu, Apr 30, 2026, 8:28 PM UTC

stonogo wrote: post #135

aduwah wrote: post #71

Earlier quoted context omitted.

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

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.