5 ms·

Why wouldn't the linux security team notify the main linux distributions?

deleted 6mo ago
[deleted]
bonzini 6mo ago
Partly they already have enough on their plate. It's up to the reporter to pick how to handle the disclosure, and unless a specific maintainer chooses to handle it, the Linux security team clearly says they won't. Partly they have a strong belief that all kernel bugs are vulnerabilities and all vulnerabilities are just bugs; sometimes taken to the extreme in both ways (on one hand this case where the vulnerability is almost ignored; on the other hand, I saw cases where a VM panic that could be triggered only by a misbehaving host—which could just choose to stop executing the VM—was given a CVE).
- baggy_trough 6mo ago
  Seems a little crazy. Somebody should evaluate blast radius and do appropriate distro notifications in a case like this (I presume the impact was part of the disclosure, so not much extra work).
  - seanhunter 6mo ago
    You know the linux kernel is a free software project right? If you think “somebody should” do a thing but you aren’t prepared to do it yourself then you should maybe ask for a full refund.
    - baggy_trough 6mo ago
      Thank you very much, seanhunter. You hit the nail on the head there.
      - bonzini 6mo ago
        Not really, because they made Linux a CNA specifically to own the process and distort it the way they want it to be.
- staticassertion 6mo ago
  This couldn't be more backwards. This has literally nothing to do with bandwidth. The kernel is a CNA, they are explicitly the ones to do this. The reason they don't is because Linus and Greg have repeatedly, publicly stated that they don't want to because they don't believe that vulnerabilities conceptually make sense for the linux kernel and they refuse to engage in the process.
  - bonzini 6mo ago
    > they don't believe that vulnerabilities conceptually make sense That's exactly what I wrote: "they have a strong belief that all kernel bugs are vulnerabilities and all vulnerabilities are just bugs; sometimes taken to the extreme in both ways". But there is also a question of bandwidth. If a maintainer asks to bring a specific vulnerability to distros-list, the kernel security people will be reasonable. I did it last March.
    - nickitolas 6mo ago
      How does that square with this comment from greg from today? https://www.openwall.com/lists/oss-security/2026/05/01/3 https://www.openwall.com/lists/oss-security/2026/05/01/3 (About heads up to distros) > 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.
      - staticassertion 6mo ago
        He's full of shit lol
      - bonzini 6mo ago
        I don't know, this is the one that I mentioned: https://www.openwall.com/lists/oss-security/2026/03/30/5 https://www.openwall.com/lists/oss-security/2026/03/30/5 You can see my name under "Timeline", I asked kindly for both distros-list and a longer embargo than usual and got them. I guess Greg is not allowed to notify distros-list, but someone else is?
bluepuma77 6mo ago
Well, how do you define main Linux distros? Isn’t the next smaller one not receiving the info always complaining?
- baggy_trough 6mo ago
  Isn't there already a distro security list for this purpose?
  - staticassertion 6mo ago
    Yes.
- throw0101a 6mo ago
  > Well, how do you define main Linux distros? Isn’t the next smaller one not receiving the info always complaining? For a first approximation: Ubuntu, Debian, RHEL(-derived) to begin with, and SuSE which is in EU/server space (AIUI): * https://commandlinux.com/statistics/most-popular-linux-distributions-market-share/ https://commandlinux.com/statistics/most-popular-linux-distr... * https://commandlinux.com/statistics/linux-server-market-share/ https://commandlinux.com/statistics/linux-server-market-shar... Seems like Gentoo, Arch, Mint, and Slackware could also be as well: * https://distrowatch.com/dwres.php?resource=major https://distrowatch.com/dwres.php?resource=major U/Deb/RHEL are 'upstream' of a lot of other projects, and fixes would trickle down to Rocky, Alma, etc. Perhaps VM OS in cloud (AWS, Azure) could be a usage gauge as well.
shimman 6mo ago
Because one of them might have an incentive to not do so. In this case it's because they want to advertise their own company.
staticassertion 6mo ago
Greg and Linus do not believe in the entire concept of "vulnerabilities" in the Linux kernel and do not believe in the methods that distros use like cherry picking, therefor they typically are against issuing CVEs, scoring CVEs, describing vulnerabilities at all (if you use the word "vulnerability", your patch will be rejected), etc. It's fundamentally their position to not work the way that you describe.
- baggy_trough 6mo ago
  That doesn't really seem to map onto the situation since Greg himself released a 6.12 with the patch earlier today.
  - staticassertion 6mo ago
    I don't know what you mean at all. I'm just repeating known kernel policy here. What does 6.12 have to do with anything?
    - baggy_trough 6mo ago
      What is your interpretation of why Greg KH released a version of 6.12 with this fix in it today, other than to help distributions avoid this vulnerability?
      - staticassertion 6mo ago
        Why would he ever... not release a new version? I don't get what you're trying to say - I'm stating Greg's explicit policy on the topic. If he did something outside of that policy, that wouldn't change anything.
        baggy_trough 6mo ago
        If he doesn't believe in the "concept of vulnerabilities" then it is remarkable that he released a 6.12 targeted on this one fix. Why would he do that otherwise?

deleted 6mo ago

[deleted]

Partly they already have enough on their plate. It's up to the reporter to pick how to handle the disclosure, and unless a specific maintainer chooses to handle it, the Linux security team clearly says they won't. Partly they have a strong belief that all kernel bugs are vulnerabilities and all vulnerabilities are just bugs; sometimes taken to the extreme in both ways (on one hand this case where the vulnerability is almost ignored; on the other hand, I saw cases where a VM panic that could be triggered only by a misbehaving host—which could just choose to stop executing the VM—was given a CVE).

baggy_trough 6mo ago
Seems a little crazy. Somebody should evaluate blast radius and do appropriate distro notifications in a case like this (I presume the impact was part of the disclosure, so not much extra work).
- seanhunter 6mo ago
  You know the linux kernel is a free software project right? If you think “somebody should” do a thing but you aren’t prepared to do it yourself then you should maybe ask for a full refund.
  - baggy_trough 6mo ago
    Thank you very much, seanhunter. You hit the nail on the head there.
    - bonzini 6mo ago
      Not really, because they made Linux a CNA specifically to own the process and distort it the way they want it to be.
staticassertion 6mo ago
This couldn't be more backwards. This has literally nothing to do with bandwidth. The kernel is a CNA, they are explicitly the ones to do this. The reason they don't is because Linus and Greg have repeatedly, publicly stated that they don't want to because they don't believe that vulnerabilities conceptually make sense for the linux kernel and they refuse to engage in the process.
- bonzini 6mo ago
  > they don't believe that vulnerabilities conceptually make sense That's exactly what I wrote: "they have a strong belief that all kernel bugs are vulnerabilities and all vulnerabilities are just bugs; sometimes taken to the extreme in both ways". But there is also a question of bandwidth. If a maintainer asks to bring a specific vulnerability to distros-list, the kernel security people will be reasonable. I did it last March.
  - nickitolas 6mo ago
    How does that square with this comment from greg from today? https://www.openwall.com/lists/oss-security/2026/05/01/3 https://www.openwall.com/lists/oss-security/2026/05/01/3 (About heads up to distros) > 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.
    - staticassertion 6mo ago
      He's full of shit lol
    - bonzini 6mo ago
      I don't know, this is the one that I mentioned: https://www.openwall.com/lists/oss-security/2026/03/30/5 https://www.openwall.com/lists/oss-security/2026/03/30/5 You can see my name under "Timeline", I asked kindly for both distros-list and a longer embargo than usual and got them. I guess Greg is not allowed to notify distros-list, but someone else is?

bluepuma77 6mo ago

Well, how do you define main Linux distros? Isn’t the next smaller one not receiving the info always complaining?

baggy_trough 6mo ago
Isn't there already a distro security list for this purpose?
- staticassertion 6mo ago
  Yes.
throw0101a 6mo ago
> Well, how do you define main Linux distros? Isn’t the next smaller one not receiving the info always complaining? For a first approximation: Ubuntu, Debian, RHEL(-derived) to begin with, and SuSE which is in EU/server space (AIUI): * https://commandlinux.com/statistics/most-popular-linux-distributions-market-share/ https://commandlinux.com/statistics/most-popular-linux-distr... * https://commandlinux.com/statistics/linux-server-market-share/ https://commandlinux.com/statistics/linux-server-market-shar... Seems like Gentoo, Arch, Mint, and Slackware could also be as well: * https://distrowatch.com/dwres.php?resource=major https://distrowatch.com/dwres.php?resource=major U/Deb/RHEL are 'upstream' of a lot of other projects, and fixes would trickle down to Rocky, Alma, etc. Perhaps VM OS in cloud (AWS, Azure) could be a usage gauge as well.

shimman 6mo ago

Because one of them might have an incentive to not do so. In this case it's because they want to advertise their own company.

staticassertion 6mo ago

Greg and Linus do not believe in the entire concept of "vulnerabilities" in the Linux kernel and do not believe in the methods that distros use like cherry picking, therefor they typically are against issuing CVEs, scoring CVEs, describing vulnerabilities at all (if you use the word "vulnerability", your patch will be rejected), etc. It's fundamentally their position to not work the way that you describe.

baggy_trough 6mo ago
That doesn't really seem to map onto the situation since Greg himself released a 6.12 with the patch earlier today.
- staticassertion 6mo ago
  I don't know what you mean at all. I'm just repeating known kernel policy here. What does 6.12 have to do with anything?
  - baggy_trough 6mo ago
    What is your interpretation of why Greg KH released a version of 6.12 with this fix in it today, other than to help distributions avoid this vulnerability?
    - staticassertion 6mo ago
      Why would he ever... not release a new version? I don't get what you're trying to say - I'm stating Greg's explicit policy on the topic. If he did something outside of that policy, that wouldn't change anything.
      - baggy_trough 6mo ago
        If he doesn't believe in the "concept of vulnerabilities" then it is remarkable that he released a 6.12 targeted on this one fix. Why would he do that otherwise?