5 ms·

>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

>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 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-vulnerabilities/ 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 5mo ago
It is literally not the vulnerability researcher's problem to solve or address this.
- SOLAR_FIELDS 5mo ago
  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_ 5mo ago
    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 5mo ago
      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_ 5mo ago
        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 5mo ago
  - gpm 5mo ago
    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 5mo ago
      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.
  - maybewhenthesun 5mo ago
    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 5mo ago
      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."
- __bjoernd 5mo ago
  If they get enough time to build a website with a fancy logo instead, one might however question where their priorities are.
  - Ukv 5mo ago
    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_ 5mo ago
      > 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 5mo ago
        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_ 5mo ago
        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
- fweimer 5mo ago
  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.
  - dwattttt 5mo ago
    > 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?
  - tptacek 5mo ago
    I think they want to showcase their ability to unearth zero-day vulnerabilities. The multi-stakeholder stuff not so much.
- nextlevelwizard 5mo ago
  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 5mo ago
    They didn’t release anything into the wild. It existed. The irresponsible thing would be letting it keep existing without telling anyone.
    - OvervCW 5mo ago
      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.
      - akerl_ 5mo ago
        Why not?
      - kasey_junk 5mo ago
        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?
      - marshray 5mo ago
        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/crypto-2.6.git/commit/?id=a664bf3d603dc3bdcf9ae47cc21e0daec706d7a5 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-2026-31431-3d65@gregkh/ 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.
- spookie 5mo ago
  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.
  - akerl_ 5mo ago
    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.
  - john_strinlai 5mo ago
    >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 5mo ago
    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.
troad 5mo ago
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.
- qotgalaxy 5mo ago
  > 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.
- deleted 5mo ago
  [deleted]
- bathtub365 5mo ago
  Where do you suggest they should have kept up on this disclosure?
- plg94 5mo ago
  > 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.
  - 5mo ago

tptacek 5mo ago

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

SOLAR_FIELDS 5mo ago
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_ 5mo ago
  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 5mo ago
    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_ 5mo ago
      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 5mo ago
- gpm 5mo ago
  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 5mo ago
    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.
- maybewhenthesun 5mo ago
  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 5mo ago
    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."
__bjoernd 5mo ago
If they get enough time to build a website with a fancy logo instead, one might however question where their priorities are.
- Ukv 5mo ago
  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_ 5mo ago
    > 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 5mo ago
      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_ 5mo ago
        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
fweimer 5mo ago
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.
- dwattttt 5mo ago
  > 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?
- tptacek 5mo ago
  I think they want to showcase their ability to unearth zero-day vulnerabilities. The multi-stakeholder stuff not so much.
nextlevelwizard 5mo ago
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 5mo ago
  They didn’t release anything into the wild. It existed. The irresponsible thing would be letting it keep existing without telling anyone.
  - OvervCW 5mo ago
    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.
    - akerl_ 5mo ago
      Why not?
    - kasey_junk 5mo ago
      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?
    - marshray 5mo ago
      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/crypto-2.6.git/commit/?id=a664bf3d603dc3bdcf9ae47cc21e0daec706d7a5 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-2026-31431-3d65@gregkh/ 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.
spookie 5mo ago
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.
- akerl_ 5mo ago
  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.
- john_strinlai 5mo ago
  >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 5mo ago
  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.

troad 5mo ago

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.

qotgalaxy 5mo ago
> 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.
deleted 5mo ago
[deleted]
bathtub365 5mo ago
Where do you suggest they should have kept up on this disclosure?
plg94 5mo ago
> 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.
- 5mo ago