I'd imagine it's not that they lacked the time to email linux-distros, but that they were unaware they were supposed to do so.

Feels like the more sensible process would be for kernel maintainers to announce when a version contains a fix for a high-impact security vulnerability and for distro maintainers to pay attention to that. Could be done without revealing what the vulnerability actually is in most cases, trusting the kernel maintainer's judgement. There does seem to be a public linux-cve-announce mailing list.

> Could be done without revealing what the vulnerability actually is in most cases

No it can’t. The bad actors that should actually worry most people are actively combing through commits on mainstream codebases, using a combination of automation/AI and manual review to pluck vulns out by their remediations.

The patch itself can be made to look fairly innocuous, as was done here. Won't always successfully prevent bad actors finding the vulnerability, but seems better to at least not unnecessarily increase that risk.

I’m saying it doesn’t matter how innocuous you try to make the patch when there are known bad actors directly evaluating every commit for “so did this close a vuln”, using both AI and human expertise.

This is true no matter what, but the comment I’m replying to was also pitching that maintainers actively call out that the patch includes a high sev security fix:

> for kernel maintainers to announce when a version contains a fix for a high-impact security vulnerability

I'm suggesting that less information about the vulnerability could be circulated than the current process, not more, due to distro maintainers being able to trust just "version X contains a fix for a high-impact security vulnerability" coming from a kernel maintainer - whereas they'll need some information/proof of that claim when coming from an outsider.

The information exposed in the current process was: code changes in the git commits and a commit message that did not mention the vulnerability.

In the current model, attackers are actively looking at all commits as potential vulnerabilities, regardless of what anybody says or doesn’t say about them.

You can’t make the commits not exist, or not be visible, because that’s a core part of how the kernel is developed and released.

So anything you do with notifications to distro maintainers about the vuln, or the existence of a vuln, or a nudge to patch with no context, or whatever, is totally irrelevant and does not change the calculus: the moment the fix is committed, bad actors who were not already aware notice it.

This is, of course, to say nothing of bad actors who had already found the vulnerability on their own.

> The information exposed in the current process was: code changes in the git commits and a commit message that did not mention the vulnerability.

Idea with the current process is for the researcher to email distro maintainers about the vulnerability - that's the part I believe could make more sense to be done by a kernel maintainer so that less information about the vulnerability has to be shared around (distro maintainers can just trust the word of the kernel maintainer that a vulnerability exists and is serious, without further evidence).

> [...] existence of a vuln, or a nudge to patch with no context, or whatever, is totally irrelevant and does not change the calculus: the moment the fix is committed, bad actors who were not already aware notice it

I'd claim this is too much binary thinking - not every vulnerability will be immediately found by every bad actor just from a well-disguised commit (like here). There are many more commits refactoring parts of code or removing complexity that don't hide a known vulnerability. More information available about the vulnerability will expedite its discovery and exploitation, so it makes sense to minimize that information where it's not necessary.

Again, the current flow was that the researchers only reported the vuln to kernel devs, who then committed a fix with no flag that it was a security fix.

A proposal where there is an unmarked commit and then anybody tells anybody anything about the fix including a security remediation is strictly more information being disclosed into the world.

Also you’re just wrong about the ability of bad actors to identify vuln remediations (and consequently vulns) by looking at commits to major projects. I don’t know what else to say here other than that this is happening, and is easily attainable via the current combination of human expertise and automated tools.

> Again, the current flow was that the researchers only reported the vuln to kernel devs

That's what happened in this case, but the current idea/expectation (according to what was linked in the comment chain I replied to) seems to be that the researcher would email the distro maintainers with information:

> > Notify [email protected], [email protected] and relevant maintainers of the vulnerability; establishing details, embargo period, CVE request and possible fix

This is the process I'm suggesting could make more sense if it was instead the kernel maintainers alerting distro maintainers (with no more detail than necessary) after a fix has made it in. Should also be less fallible than relying on the researcher to do so.

> Also you’re just wrong about the ability of bad actors to identify vuln remediations (and consequently vulns) by looking at commits to major projects. I don’t know what else to say here other than that this is happening, and is easily attainable via the current combination of human expertise and automated tools

I don't deny that bad actors can figure out vulnerabilities from tracking commits, but removing or refactoring some subsystem does not immediately give all bad actors a full list of vulnerabilities with the old version. Developing an abusable exploit chain (as may be shown by the researcher to justify high priority patching) is also not necessarily trivial even if they do figure out an issue that was fixed.