[fresh_broccoli]

>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-known practice: https://sam4k.com/a-dummys-guide-to-disclosing-linux-kernel-...

I agree it's a shame that the process isn't more streamlined and the kernel developers aren't forwarding the reports to the distros list.

[tptacek]

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

[SOLAR_FIELDS]

Agree, but then where does the accountability lie? Presumably with the kernel maintainers themselves, correct? SOMEONE dropped the ball here. If we can't point the finger correctly, that seems like a problem in of itself.

[akerl_]

It looks like the expected thing happened.

The kernel devs patched the kernel. The kernel devs have a pretty known, straightforward stance in how they ship fixes for anything, because anything in the kernel can be a security problem.

Distro maintainers can see kernel changes. Some distros aggressively track new changes. Others backport what they feel are relevant. Others don’t do either.

Users pick what distro they use, and how they set up their infra.

Maybe if I were paying for RHEL licenses I’d be eyeballing the money I pay and RHEL’s response time.

But the ownership here lies with system operators, who pick their infrastructure, who design their security model, and who build their operational workflows. This vuln is a great example: people who looked at shared untrusted workloads on a single kernel and said “Hell no” had a much calmer day than teams who thought that was a good idea.

[SOLAR_FIELDS]

The fact that you had to take a whole paragraph to explain the contortionist arrival at something that isn't even really super clear after you explained it (you kinda pointed the finger both at end users and at distro maintainers simultaneously) and essentially boils down to "well, you as the end user need to be following kernel CVE's and can't trust distro maintainers to do it" does in fact indicate that there is a deeper issue at play here. You might say "well, there's no implicit chain of trust here". You might be right, but is that really the most effective way of doing things? Of course Linux is Use it at your Own Risk, but is there not a concept of "we as a collective community should get together and try not to drop the ball on some serious shit?"

In terms of something actionable, and maybe someone more well versed in how the distros work can tell me why this is a bad idea, but shouldn't there be a documented process and channel for critical CVE's to be bubbled out to distro maintainers who then have some sort of SLA for patching them and sending them downstream to end users? Perhaps incentives are not aligned to produce this outcome.

[akerl_]

To be more blunt: if you’re paying for a product, the vendor owes you whatever things they committed to. If you’re a Redhat customer and your agreed SLA with Redhat for this kind of security fix was passed by, go be mad at Redhat. (I don’t think Redhat is bad here, they’re just the vendor most known for a commercial offering from the lists here. I would say the same thing about Ubuntu Pro)

Otherwise, it’s on the end user. Distro volunteers don’t owe you anything. Kernel devs don’t owe you anything.

I don’t care about what would be the most effective way of doing things. I care about what folks involved actually owe to each other, and distro volunteers don’t owe users any kind of active chasing of remediation due to the user’s threat model.

The idea of making some kind of streamlined process that solves what you didn’t like about this vulnerability’s remediation is that it ignores basically all the complexity. Like “what about distros that don’t abide by embargoes” or “what distros count as ones that matter” or “what about all the vulns that aren’t in Linux, they’re in software that’s packaged across many operating systems”.

[SOLAR_FIELDS]

Right, you’re saying “system is working as designed”, and I’m agreeing, but I’m saying “the system as designed kind of sucks, how can we make it better”?

[komali2]

Just as a purely intellectual exercise, what changes about this if we leave aside ideas of "owe," "deserve ," and "earn?"

There's not really an enforcement mechanism in FOSS like there is in capitalism world, it just comes down to what we want our part of the world to look like. So I think we'd think more clearly if we leave aside the ideas like "who owes who what." I think it's fun to imagine what sort of motivations and incentives there are if we put away the money ones.

[QuiEgo]

Agree on this so hard. Why does everyone expect instant patches and SLA-like infrastructure from unpaid volunteers?

If you want that, buy a commercial distro of linux, or use Windows. That's a huge part of Microsoft's value proposition to enterprise - they pay people to stay on top of security patches for you. Same with RedHat and others.

Expecting anything of unpaid volunteers is unreasonable.

> THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.

[hnfong]

> In terms of something actionable, and maybe someone more well versed in how the distros work can tell me why this is a bad idea, but shouldn't there be a documented process and channel for critical CVE's to be bubbled out to distro maintainers who then have some sort of SLA for patching them and sending them downstream to end users? Perhaps incentives are not aligned to produce this outcome.

Who decides who is a trustworthy distro maintainer? In the open source world everyone is equal, no favorites are chosen. If your point is that the distros backed by companies making at least $x million revenue a year should get priority disclosure... pretty sure somebody will take issue with this.

And it's not like a hypothetical issue either. Given the high stakes, bad actors are highly incentivized to masquerade as some small scale niche distro until they get their effectively free zero day CVE.

[SOLAR_FIELDS]

I wanted to share with you that I took some time to reflect on this response and I now agree that this is correct. To ask Linux to add some central authority, no matter how good-intended it is, is antithetical to how Linux works. We must accept that this is a side effect of the purism that requires Linux to function. Can we do better? Probably. But we shouldn’t give up the point of why we are doing this in the first place - and to declare such centralized authority would be doing so, IMO

[PearlRiver]

The real advantage of Microsoft is that there is someone you can sue!

Linux like every open source project is just a bunch of people who are YOLOing it. Not something you use for your fortune 500 critical mission infrastructure.

[anygivnthursday]

https://github.com/microsoft/azurelinux

[sirl1on]

I thought this is why red has exists?

[thayne]

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

[dbdr]

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

[jurgenburgen]

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.

[maybewhenthesun]

The distros dropped the ball. imho. One of the (main) tasks of the distro is watching the changed of you upstream packages for important changes. This is slightly complicated by the fact that the linux kernel considers all bugfixes security fixes, so it's quite a lot to read it all. But that's life. The kernel developers are not wrong as it's nearly impossible to be sure a bug in the kernel is not (also) a security problem.

[Dylan16807]

The patch wasn't even listed as fixing a bug.

"There is no benefit in operating in-place in algif_aead since the source and destination come from different mappings. Get rid of all the complexity added for in-place operation and just copy the AD directly."

[gpm]

The accountability fundamentally lies with the distro maintainers. They're the ones shipping a "product". Either they need to get agreements in place for advance notice, or correctly set expectations with their users that they won't get advanced notice.

They dropped the ball when the shipped supposedly secure systems where their method for getting alerted to security updates was "hope people reporting to upstream will also notice a mailing list that will alert them".

(Caveat: Distro's like Ubuntu advertise security updates so this is on them. I'm not sure Gentoo does that, if they don't well then no one dropped the ball because no one represented that Gentoo got prompt security updates).

[cdud3]

All it takes is to be part of the Kernel security team. I am surprised that many commercial strong distributors just not care enough to join the Kernel security team. Hopefully a valuable lesson was learned and fixes are applied.

[spookie]

Brother, it is a simple email to a mailing list.

They are professional security researchers, they must know this is the way it is done in the ecosystem.

Kicking the can around leads nowhere.

[john_strinlai]

>Brother, it is a simple email to a mailing list.

just as a note, its not as simple as firing off an email to linux-distros and calling it a day.

qualys, one of the big firms (10,000+ customers across 130 countries. i.e. "professional researchers"), has even taken a stance against emailing linux-distros because of the restrictions and policies involved:

    > Although contacting the linux-distros list has been clearly beneficial
    > (they have thoroughly reviewed and tested the patches, and were able to
    > prepare their kernel updates beforehand), we have reached the conclusion
    > that it has become increasingly difficult to coordinate the disclosure
    > of kernel vulnerabilities with both groups (the Linux kernel security
    > team and the linux-distros list), because they have very different
    > policies. From now on, we will coordinate the disclosure of kernel
    > vulnerabilities with the Linux kernel security team only. We also
    > apologize in advance for this.

[tptacek]

Of course you want them to have sent an email to a mailing list. You're on a message board, and weren't involved in their disclosure process. Why not ask for everything that sounds reasonable to you? There's no cost to it for you. Maybe you can set their OKRs while you're at it.

There are (some, loose) norms of vulnerability disclosure, and this isn't one of them.

[akerl_]

Have you considered that maybe it’s not the way it’s done?

It’s certainly a thing some people do. But there is not a unified consensus on how to handle vulnerabilities. Different security researchers (or, in fact, the same researchers releasing different findings) can and do take many different courses of action.

[fweimer]

If you just want to get a bug fixed that annoys you, it's of course out of scope.

If researchers want to showcase their ability (either individually or as an organization) to identify and address security vulnerabilities in complex multi-stakeholder environments, I very much expect them to figure this out. After all, it doesn't make much sense if a company, after commissioning a security review, needs to hire a different firm to handle the vendor interactions, so that identified issues are resolved with minimal impact to the business.

[tptacek]

I think they want to showcase their ability to unearth zero-day vulnerabilities. The multi-stakeholder stuff not so much.

[dwattttt]

> a company, after commissioning a security review, needs to hire a different firm to handle the vendor interactions

These vendor interactions you're referring to are the company's customers, correct? Are you proposing the company hire another company to manage getting updates to their customers?

[nextlevelwizard]

That is just being pedantic. Why did they absolutely need to release this into the wild now? Why couldn’t they have waited?

“30 days should be enough time” why? Why is 30 days a magic number? Especially in open source.

Yeah it isn’t the researchers problem to tell every distributor of the kernel about the fix or verify that everyone has the fix, but fuck maybe wait until at least someone has the fix and maybe don’t drop it on a Friday. That is just malicious

[kasey_junk]

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

[OvervCW]

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.

[marshray]

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.

[kasey_junk]

I do deny that, mostly because we’ve entered the time of automated vulnerability detection and abuse. A human need not be in the loop at all anymore.

But, even if I agreed with you, how do you propose they tell the patchers this that doesn’t tell the whole world?

[akerl_]

Why not?

[nextlevelwizard]

So why not just tell immediately on discovery? After all every flaw exists already so what’s the difference?

[kasey_junk]

That would have been fine too?

[Dylan16807]

What number of days do you want? If nobody tells the distros it could be months or years, and while it would be nice for the researchers to monitor/notify distros it's really not their job. They might not have thought of it.

And they dropped it on a Wednesday.

[nextlevelwizard]

Yes. I misspoke. It dropped very very late on Wednesday, most of the work started on Thursday and Friday was a Mayday which is a holiday in many if not most places. So fine, on a technicality it wasn't a Friday release, but it might as well have been. They could have easily waited for Monday.

[Dylan16807]

This is really stretching. Releasing very very late on a "Thursday" is fine. That gives you an entire day to pause everything else, set up mitigations, and see if things still seem to be working. If a whole work day isn't enough then you were probably going to have trouble no matter what day of the week they published. Late late "Thursday" doesn't have to be your favorite but it's not malicious.

Also it was evening UTC but only like noon Pacific time.

[__bjoernd]

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

[Ukv]

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.

[akerl_]

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

[Ukv]

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.

[akerl_]

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

[troad]

Why is it the job of the kernel to notify the distros? Why isn't it the job of the distros to keep up on upstream security disclosures?

Expecting a FOSS project to go track down all of its (millions of?) users seems like a very unreasonable expectation, and is well outside of their scope of responsibility.

People have gotten so used to the Github flavour of free-labour, social-network-style FOSS that they've forgotten what all those LICENSE files actually say, which is to make it explicitly clear that the devs are not responsible to you for your issues, up to and including the software setting your house on fire. If you don't like it, you don't have to use it.

[plg94]

> Why isn't it the job of the distros to keep up on upstream security disclosures?

They can't, because (responsible) security disclosures are private, _not public_. That's the whole point of the system: notify the developers in private ahead of time (usually 30, 60 or 90 days) so they can write, test and roll-out the fixes before you release the info to the whole world. This is to minimize the time between when bad actors gain access to the exploits vs. when users install the patch. So "keeping up on security disclosures" cannot ever be a 'pull' process.

Usually the maintainers of the big distros are part of (private) security mailinglists and receive such info. Just not in this case it seems.

[krzyk]

It would be best if distros kept tap on kernel changes and update as soon as possible when they see a security issue fixed.

Sending emails to some big distros would still result with e.g. Gentoo not getting that info because they are not a big distro.

[maybewhenthesun]

The problem is that the kernel devs (correctly imo) consider all bugfixes security fixes. So the distros need to decide for themselves which ones are important enough to warrant an update. Apparently this one had a quite unclear commit message, so it importance was missed.

Not ideal, but also: shit happens? It's always a balancing act choosing the lesser of multiple evils and most of the time it seems to work ok-ish, which is probably the best we can hope for ;-P

[gpvos]

The kernel maintainers don't flag "security fixes" as special, and they have a well-thought-out reason for that, see many other comments in this thread.

[__bjoernd]

That, and they flag pretty much any random patch with a CVE these days, making it harder for distro maintainers to keep up.

For this specific "bug" they took care to not mention any security angle in the commit message, making it extremely hard for an outsider to even realize this was a critical patch. I assume this was because they wanted to push the fix without breaking embargo.

[bathtub365]

Where do you suggest they should have kept up on this disclosure?

[qotgalaxy]

> Expecting a FOSS project to go track down all of its (millions of?) users seems like a very unreasonable expectation, and is well outside of their scope of responsibility.

The post you are responding to says that it would be nice if they copied literally one mailing list.