8 ms·

i have no problem with disclosing a vulnerability 30 days after its patched in the thing you reported to. (in fact, for those unaware, this is the same policy t

i have no problem with disclosing a vulnerability 30 days after its patched in the thing you reported to. (in fact, for those unaware, this is the same policy that google's project zero uses: "90+30" https://projectzero.google/vulnerability-disclosure-policy.html https://projectzero.google/vulnerability-disclosure-policy.h...) the real problem is: >It's also worrying that it seems there's no communication between the kernel security team and distribution maintainers. the reporter should not be the one responsible for reporting separately to every single downstream of the thing they found a vuln in. what should be happening, as you allude to, is a communication channel between the kernel security team and distribution maintainers. they are in a much better position to coordinate and communicate with the maintainers than random reporters are. the minute the patch landed in the kernel, a notification should have gone out from the kernel team to a curated list of distro security folk that communicated the importance of the patch, and that the public disclosure would be in 30 days.

ori_b 6mo ago
If the maintainers were unresponsive, sure -- but it seems slightly hard to buy that a responsible reporter trying to make a big splash and a good impression wouldn't first check "did this make it out to the distros?" before making sysadmin's days real shitty, even if technically they could point fingers at other parties. At which point, if they're paying paying any attention at all to what they reported, they may have realized that a mistake was made.
- john_strinlai 6mo ago
  its an industry standard disclosure process. 90 days after reporting, or 30 days after the patch lands, the vuln is disclosed. the linux kernel team is in a 10000% better position to communicate to and coordinate their downstreams. it seems completely backwards to me to suggest that the reporter should be responsible for figuring out every possible downstream and opening up separate reports to each of them. the kernel team should have a process/channel to say "this is important! disclosure is in 30 days" that is received by distro security teams. because this is not the first or last time the kernel will have a local privilege escalation. hoping that every reporter, forever in the future, will take the onus on themselves is a recipe for disapointment.
  - ori_b 6mo ago
    Yes, it's just incompetence from everyone involved, not malice. The company making the disclosure doesn't actually care, and the kernel processes are ineffective.
    - tptacek 6mo ago
      No, it's incompetence from everyone involved except the company making the disclosure, which, despite the fact that the existing norms are not in fact binding (like people downthread seem to believe), they followed.
      - ori_b 6mo ago
        Really? It seems very odd to not check in on the status of the fixes, even if it's technically possible to pass the blame to other people. Even if the only purpose of looking at the status to make yourself look good in marketing materials, it's surprising that it didn't happen.
        Joker_vD 6mo ago
        One of the reasons this unavoidable deadline was invented, is that the alternative is that one company (or all of them) can simply decide to ignore the vuln report, and then the vulnerability will stay forever undisclosed and forever out there in the wild. And prisoner's dilemma suggests that most companies would chose "do nothing" in this scenario: they don't have to do anything, and if the vuln stays undisclosed, it probably won't be exploited anyhow. Win-win!
        ori_b 6mo ago
        I'm confused. Can you explain how this applies to the current situation, where no vuln reports were submitted to the groups responsible for distributing patches?
        john_strinlai 6mo ago
staticassertion 6mo ago
> they are in a much better position to coordinate and communicate with the maintainers than random reporters are. They openly refuse to do this and have been given authority by MITRE to work against any such process.
- john_strinlai 6mo ago
  right, which is why it is confusing that the animosity is aimed at the reporters rather than the kernel security team.
  - expedition32 6mo ago
    Not really confusing. Linux is a sacred cow. There would be a lot of people gloating if this happened to MS.
    - stackghost 6mo ago
      Microsoft has a long and sordid history of cheerfully doing anything they can to fuck everyone over just to make a few more percentage points of profit. Linux is a free kernel that literally revolutionized the computing landscape.
      - dwattttt 6mo ago
        Yes, this is the sacred cow status being referred to.
        maybewhenthesun 6mo ago
        It might be a scared cow, but at least deservedly so. There is imho a difference between accidental incompetence (debatable, even) and active malice. Microsoft has done a lot of the latter so gets bashed more, nor surprise there.
        Brian_K_White 6mo ago
        "You keep using that word..." or term in this case. There are only 2 words in this term, and neither one even slightly applies. A sacred cow is called a sacred cow because there is no reason for it to be sacred. Linux is perfectly subject to criticism, and so not at all sacred. Linux has earned a stunning amount of respect and gratitude by actually providing stunning utility and quality. IE, it's not just a random object like a cow that everyone decided to worship for no reason. Spoken as a freebsd user who has plenty of critiques of the entire linux ecosystem.
Denvercoder9 6mo ago
Two things can be true simultaneously: the Linux kernel ecosystem should have done better at communicating this to their downstreams, and publicly sharing the exploit was irresponsible. It is not the responsibility of the initial reporter to communicate to distributions, but the fact that those responsible failed to do that, doesn't give everybody else a free pass.
- x4132 6mo ago
  so what? we should never disclose anything? this will only result in companies suppressing disclosure and leaving vulnerabilities unpatched.
- john_strinlai 6mo ago
  >publicly sharing the exploit was irresponsible they did it in the established industry standard way that probably every single security researcher you can think of follows (for good reason, i would add). whoever did the marketing on "responsible disclosure" was a genius. tptacek says it much better than me: ""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."
  - Denvercoder9 6mo ago
    In my world, responsibility is not just checking a box of following industry practice. Responsibility, as Wikipedia puts it on their social responsibility page, is working together with others for the benefit of the community. And yes, sometimes that's a bit larger burden than would ideally be the case. It's an imperfect world, after all -- and let's not forget the disclosure as it happened also placed a larger burden than ideal on people scrambling to patch. And it's not as if I'm asking for a lot of effort. One mail to the security team of a popular distro "hey, we have found this LPE that we'll release with exploit next week, it's patched upstream already in this commit, but you don't seem to have picked it up" would likely have been enough.
    - da_chicken 6mo ago
fresh_broccoli 6mo ago
>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 6mo ago
  It is literally not the vulnerability researcher's problem to solve or address this.
  - SOLAR_FIELDS 6mo 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_ 6mo 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.
deleted 6mo ago
[deleted]
steve1977 6mo ago
> a notification should have gone out from the kernel team to a curated list of distro security folk Who would curate that list though? You don't need permission from the kernel team to spin up a new distro. I can go and create fork of Debian or Arch or whatever today and the kernel team would never know (and neither should they). This is completely in the responsibility of the distros. If you don't like this model, use something like FreeBSD.
- mort96 6mo ago
  Sounds like a job for the Linux Foundation maybe? You don't need anyone's permission to make a distro, that's true, but if you notify Debian, Canonical, Fedora, Red Hat and Arch you're covering a very large fraction of users; way more than today's 0%. In cases like this, perfect is the enemy of the good.
  - dotancohen 6mo ago
    A rogue actor may create a new distro, maybe for some niche use case such as accessibility or retro gaming. After acquiring enough false (and even some real) users that the Linux Foundation accepts them as a notifiable distro maintainer, this maintainer could then pwn machines before the exploit is made public.
    - danlitt 6mo ago
      Rather than the current situation, where they can pwn machines after the exploit is made public?
      - dotancohen 6mo ago
        Yes. After the exploit is made public, the window of opportunity closes quickly.
        danlitt 6mo ago
        Not if people don't get notified!
paulnpace 6mo ago
> the reporter should not be the one responsible for reporting separately to every single downstream of the thing they found a vuln in. It's 2026. We're more than 30 years into the Linux ecosystem. I don't believe this bullshit for a moment. Given how trivially users can implement mitigation, distributions could have done _something_ to protect their users prior to publication date. A handful of messages is all that was required, not "every single downstream" - that is a straw man. The publication of a bug that trivially gains root on an incredible number of Linux installs that was discovered using an A.I. tool prior to any of the "downstreams" implementing a fix is intentional. I speculate the motivation is free promotion of the A.I. tool.
- john_strinlai 6mo ago
  >distributions could have done _something_ to protect their users prior to publication date. yeah, distributions could be following the kernel updates more closely and they would have been patched prior to publication. mainline was patched 30 days before publication. it is not the reporter's responsibility to babysit the linux distributions.
  - paulnpace 6mo ago
    And here, with this comment, we see how the overall system functions: nobody actually cares what is going on with anything outside of themselves. It is a large group of individualized nihilists with total disregard to everyone, and you will provide lengthy justifications to maintain this system, as is.
    - tptacek 6mo ago
      It is a large group of people with their own incentives, and you're surprised they aren't self-organizing (or accepting outside pressure) to align with your own incentives.
    - akerl_ 6mo ago
      Ah yes, all those nihilists spending their spare time volunteering as developers and maintainers of open source projects.

ori_b 6mo ago

If the maintainers were unresponsive, sure -- but it seems slightly hard to buy that a responsible reporter trying to make a big splash and a good impression wouldn't first check "did this make it out to the distros?" before making sysadmin's days real shitty, even if technically they could point fingers at other parties. At which point, if they're paying paying any attention at all to what they reported, they may have realized that a mistake was made.

john_strinlai 6mo ago
its an industry standard disclosure process. 90 days after reporting, or 30 days after the patch lands, the vuln is disclosed. the linux kernel team is in a 10000% better position to communicate to and coordinate their downstreams. it seems completely backwards to me to suggest that the reporter should be responsible for figuring out every possible downstream and opening up separate reports to each of them. the kernel team should have a process/channel to say "this is important! disclosure is in 30 days" that is received by distro security teams. because this is not the first or last time the kernel will have a local privilege escalation. hoping that every reporter, forever in the future, will take the onus on themselves is a recipe for disapointment.
- ori_b 6mo ago
  Yes, it's just incompetence from everyone involved, not malice. The company making the disclosure doesn't actually care, and the kernel processes are ineffective.
  - tptacek 6mo ago
    No, it's incompetence from everyone involved except the company making the disclosure, which, despite the fact that the existing norms are not in fact binding (like people downthread seem to believe), they followed.
    - ori_b 6mo ago
      Really? It seems very odd to not check in on the status of the fixes, even if it's technically possible to pass the blame to other people. Even if the only purpose of looking at the status to make yourself look good in marketing materials, it's surprising that it didn't happen.
      - Joker_vD 6mo ago
        One of the reasons this unavoidable deadline was invented, is that the alternative is that one company (or all of them) can simply decide to ignore the vuln report, and then the vulnerability will stay forever undisclosed and forever out there in the wild. And prisoner's dilemma suggests that most companies would chose "do nothing" in this scenario: they don't have to do anything, and if the vuln stays undisclosed, it probably won't be exploited anyhow. Win-win!
        ori_b 6mo ago
        I'm confused. Can you explain how this applies to the current situation, where no vuln reports were submitted to the groups responsible for distributing patches?
        john_strinlai 6mo ago

staticassertion 6mo ago

> they are in a much better position to coordinate and communicate with the maintainers than random reporters are. They openly refuse to do this and have been given authority by MITRE to work against any such process.

john_strinlai 6mo ago
right, which is why it is confusing that the animosity is aimed at the reporters rather than the kernel security team.
- expedition32 6mo ago
  Not really confusing. Linux is a sacred cow. There would be a lot of people gloating if this happened to MS.
  - stackghost 6mo ago
    Microsoft has a long and sordid history of cheerfully doing anything they can to fuck everyone over just to make a few more percentage points of profit. Linux is a free kernel that literally revolutionized the computing landscape.
    - dwattttt 6mo ago
      Yes, this is the sacred cow status being referred to.
      - maybewhenthesun 6mo ago
        It might be a scared cow, but at least deservedly so. There is imho a difference between accidental incompetence (debatable, even) and active malice. Microsoft has done a lot of the latter so gets bashed more, nor surprise there.
      - Brian_K_White 6mo ago
        "You keep using that word..." or term in this case. There are only 2 words in this term, and neither one even slightly applies. A sacred cow is called a sacred cow because there is no reason for it to be sacred. Linux is perfectly subject to criticism, and so not at all sacred. Linux has earned a stunning amount of respect and gratitude by actually providing stunning utility and quality. IE, it's not just a random object like a cow that everyone decided to worship for no reason. Spoken as a freebsd user who has plenty of critiques of the entire linux ecosystem.

Denvercoder9 6mo ago

Two things can be true simultaneously: the Linux kernel ecosystem should have done better at communicating this to their downstreams, and publicly sharing the exploit was irresponsible. It is not the responsibility of the initial reporter to communicate to distributions, but the fact that those responsible failed to do that, doesn't give everybody else a free pass.

x4132 6mo ago
so what? we should never disclose anything? this will only result in companies suppressing disclosure and leaving vulnerabilities unpatched.
john_strinlai 6mo ago
>publicly sharing the exploit was irresponsible they did it in the established industry standard way that probably every single security researcher you can think of follows (for good reason, i would add). whoever did the marketing on "responsible disclosure" was a genius. tptacek says it much better than me: ""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."
- Denvercoder9 6mo ago
  In my world, responsibility is not just checking a box of following industry practice. Responsibility, as Wikipedia puts it on their social responsibility page, is working together with others for the benefit of the community. And yes, sometimes that's a bit larger burden than would ideally be the case. It's an imperfect world, after all -- and let's not forget the disclosure as it happened also placed a larger burden than ideal on people scrambling to patch. And it's not as if I'm asking for a lot of effort. One mail to the security team of a popular distro "hey, we have found this LPE that we'll release with exploit next week, it's patched upstream already in this commit, but you don't seem to have picked it up" would likely have been enough.
  - da_chicken 6mo ago

fresh_broccoli 6mo ago

>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 6mo ago
It is literally not the vulnerability researcher's problem to solve or address this.
- SOLAR_FIELDS 6mo 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_ 6mo 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.

deleted 6mo ago

[deleted]

steve1977 6mo ago

> a notification should have gone out from the kernel team to a curated list of distro security folk Who would curate that list though? You don't need permission from the kernel team to spin up a new distro. I can go and create fork of Debian or Arch or whatever today and the kernel team would never know (and neither should they). This is completely in the responsibility of the distros. If you don't like this model, use something like FreeBSD.

mort96 6mo ago
Sounds like a job for the Linux Foundation maybe? You don't need anyone's permission to make a distro, that's true, but if you notify Debian, Canonical, Fedora, Red Hat and Arch you're covering a very large fraction of users; way more than today's 0%. In cases like this, perfect is the enemy of the good.
- dotancohen 6mo ago
  A rogue actor may create a new distro, maybe for some niche use case such as accessibility or retro gaming. After acquiring enough false (and even some real) users that the Linux Foundation accepts them as a notifiable distro maintainer, this maintainer could then pwn machines before the exploit is made public.
  - danlitt 6mo ago
    Rather than the current situation, where they can pwn machines after the exploit is made public?
    - dotancohen 6mo ago
      Yes. After the exploit is made public, the window of opportunity closes quickly.
      - danlitt 6mo ago
        Not if people don't get notified!

paulnpace 6mo ago

> the reporter should not be the one responsible for reporting separately to every single downstream of the thing they found a vuln in. It's 2026. We're more than 30 years into the Linux ecosystem. I don't believe this bullshit for a moment. Given how trivially users can implement mitigation, distributions could have done _something_ to protect their users prior to publication date. A handful of messages is all that was required, not "every single downstream" - that is a straw man. The publication of a bug that trivially gains root on an incredible number of Linux installs that was discovered using an A.I. tool prior to any of the "downstreams" implementing a fix is intentional. I speculate the motivation is free promotion of the A.I. tool.

john_strinlai 6mo ago
>distributions could have done _something_ to protect their users prior to publication date. yeah, distributions could be following the kernel updates more closely and they would have been patched prior to publication. mainline was patched 30 days before publication. it is not the reporter's responsibility to babysit the linux distributions.
- paulnpace 6mo ago
  And here, with this comment, we see how the overall system functions: nobody actually cares what is going on with anything outside of themselves. It is a large group of individualized nihilists with total disregard to everyone, and you will provide lengthy justifications to maintain this system, as is.
  - tptacek 6mo ago
    It is a large group of people with their own incentives, and you're surprised they aren't self-organizing (or accepting outside pressure) to align with your own incentives.
  - akerl_ 6mo ago
    Ah yes, all those nihilists spending their spare time volunteering as developers and maintainers of open source projects.