Huh, this is interesting. Normally the reason to become a CNA is to reduce the amount of bogus CVEs that are issued for your project due to security researchers trying to pad their portfolio.
Linux seems to have taken the reverse approach, by just filing their own bogus CVEs instead. One for every bug fix going into the kernel, rendering the CVE system useless.
> One for every bug fix going into the kernel, rendering the CVE system useless.
That is not what they're doing at all, things get CVEs by a small 3 people committee judging on whether it may reasonably have security impact.
If this is rendering CVEs useless to you, then you were misusing CVEs to begin with. CVEs are identifiers. The fact that an identifier is assigned does not mean anything about whether the security issue is real and/or its severity. Assigning an ID was meant to help discussing things, including determining whether it is in fact a security issue.
k so I'm writing a blog post on the whole #Linux Kernel #CVE/#CNA thing. And I actually looked at the data. For those of you complaining about the Linux Kernel issuing improper CVEs my response is "cool. If they're not security vulns get them rejected".
So far in 2024 the Linux Kernel error rate is 3.21%.
Is that bad or good?
Let's compare to the top 25 CNA's by error rate for 2024:
f5 49.32%
atlassian 44.44%
Esri 43.75%
freebsd 40.00%
canonical 32.61%
Gallagher 25.00%
SNPS 25.00%
intel 19.74%
Anolis 18.75%
Dragos 18.18%
rapid7 14.29%
@huntr_ai 12.27%
Google 10.00%
directcyber 8.33%
CERTVDE 8.11%
Go 7.69%
lenovo 6.25%
mitre 5.53%
schneider 4.35%
GitHub_P 4.35%
Fluid Attacks 4.35%
Wordfence 3.56%
Linux 3.21%
snyk 2.94%
So... Linux is in at 24th place for error rate. But wait, surely those numbers are skewed towards some smaller CNAs that reject a handful of issues driving up their error rate?
Nope. Several of the mature CNAs like F5, Atlassian, Canonical, Google, Intel, Red Hat, Lenovo, MITRE all issue tens to hundreds to thousands of CVEs a year and have much higher error rates. Actually the worst CNA by raw numbers is MITRE (159).
Spamming this multiple times since people don't seem to read.
> Despite existing for a little over four months and in that time assigning over 2000 CVEs at a faster rate than any other CNA in existence, the harm it's single-handedly caused to the CVE ecosystem hasn't been fully appreciated yet by the public and is mostly relegated to security teams of downstream distributions,
Is this related to the fact that the NIST NVD have had a huge backlog of unprocessed CVE:s since February?
> Despite existing for a little over four months and in that time assigning over 2000 CVEs at a faster rate than any other CNA in existence, the harm it's single-handedly caused to the CVE ecosystem hasn't been fully appreciated yet by the public and is mostly relegated to security teams of downstream distributions, vulnerability management companies, and end-users who noticed recently their previously-informative distribution security advisories got replaced with auto-generated lists of hundreds of CVEs with minimal user-understandable/actionable information.
Good! We have environmental CVSS scores now, use them.
Assigning a CVE to every second commit and refusing to assign CVEs to unfixed issues doesn't seem like correct usage of the CVE system. I expect that most Linux CVEs will never get a proper analysis or a CVSS rating.
To me it sounds plausible that the design goal of the Linux CNA is to show that CVEs don't meaningfully apply to the Linux kernel. Given how dependent on context the impact of some kernel bugs can be, if we were assigning CVSS scores for the worst case, practically all kernel bugs would be at least a 9.8/10.
Ah, you're paying for some enterprise Linux subscription, then? So that the vendor can on your (and others') behalf influence the kernel devs that they are funding?
Honestly, I think your reactions just show that you don't really understand why the kernels devs behavior in this context is so childish and irresponsible.
k so I'm writing a blog post on the whole #Linux Kernel #CVE/#CNA thing. And I actually looked at the data. For those of you complaining about the Linux Kernel issuing improper CVEs my response is "cool. If they're not security vulns get them rejected".
So far in 2024 the Linux Kernel error rate is 3.21%.
Is that bad or good?
Let's compare to the top 25 CNA's by error rate for 2024:
f5 49.32%
atlassian 44.44%
Esri 43.75%
freebsd 40.00%
canonical 32.61%
Gallagher 25.00%
SNPS 25.00%
intel 19.74%
Anolis 18.75%
Dragos 18.18%
rapid7 14.29%
@huntr_ai 12.27%
Google 10.00%
directcyber 8.33%
CERTVDE 8.11%
Go 7.69%
lenovo 6.25%
mitre 5.53%
schneider 4.35%
GitHub_P 4.35%
Fluid Attacks 4.35%
Wordfence 3.56%
Linux 3.21%
snyk 2.94%
So... Linux is in at 24th place for error rate. But wait, surely those numbers are skewed towards some smaller CNAs that reject a handful of issues driving up their error rate?
Nope. Several of the mature CNAs like F5, Atlassian, Canonical, Google, Intel, Red Hat, Lenovo, MITRE all issue tens to hundreds to thousands of CVEs a year and have much higher error rates. Actually the worst CNA by raw numbers is MITRE (159).
Spamming this multiple times since people don't seem to read.
> This oversight meant that in affected kernels with the bad backport [...] not only was the MDS mitigation against the newer attacks turned into a no-op [...]
Huh, this is interesting. Normally the reason to become a CNA is to reduce the amount of bogus CVEs that are issued for your project due to security researchers trying to pad their portfolio.
Linux seems to have taken the reverse approach, by just filing their own bogus CVEs instead. One for every bug fix going into the kernel, rendering the CVE system useless.
> One for every bug fix going into the kernel, rendering the CVE system useless.
That is not what they're doing at all, things get CVEs by a small 3 people committee judging on whether it may reasonably have security impact.
If this is rendering CVEs useless to you, then you were misusing CVEs to begin with. CVEs are identifiers. The fact that an identifier is assigned does not mean anything about whether the security issue is real and/or its severity. Assigning an ID was meant to help discussing things, including determining whether it is in fact a security issue.
k so I'm writing a blog post on the whole #Linux Kernel #CVE/#CNA thing. And I actually looked at the data. For those of you complaining about the Linux Kernel issuing improper CVEs my response is "cool. If they're not security vulns get them rejected".
So far in 2024 the Linux Kernel error rate is 3.21%.
Is that bad or good?
Let's compare to the top 25 CNA's by error rate for 2024:
f5 49.32%
atlassian 44.44%
Esri 43.75%
freebsd 40.00%
canonical 32.61%
Gallagher 25.00%
SNPS 25.00%
intel 19.74%
Anolis 18.75%
Dragos 18.18%
rapid7 14.29%
@huntr_ai 12.27%
Google 10.00%
directcyber 8.33%
CERTVDE 8.11%
Go 7.69%
lenovo 6.25%
mitre 5.53%
schneider 4.35%
GitHub_P 4.35%
Fluid Attacks 4.35%
Wordfence 3.56%
Linux 3.21%
snyk 2.94%
So... Linux is in at 24th place for error rate. But wait, surely those numbers are skewed towards some smaller CNAs that reject a handful of issues driving up their error rate?
Nope. Several of the mature CNAs like F5, Atlassian, Canonical, Google, Intel, Red Hat, Lenovo, MITRE all issue tens to hundreds to thousands of CVEs a year and have much higher error rates. Actually the worst CNA by raw numbers is MITRE (159).
Spamming this multiple times since people don't seem to read.
Turns out F5 and Intel were just clearing out old reservations, but the other data is correct.
Not really what's going on here.
It's only when they can't be sure there are not security implications. After all they don't try to build all combinations and so on.
> Despite existing for a little over four months and in that time assigning over 2000 CVEs at a faster rate than any other CNA in existence, the harm it's single-handedly caused to the CVE ecosystem hasn't been fully appreciated yet by the public and is mostly relegated to security teams of downstream distributions,
Is this related to the fact that the NIST NVD have had a huge backlog of unprocessed CVE:s since February?
https://www.nist.gov/itl/nvd
> Despite existing for a little over four months and in that time assigning over 2000 CVEs at a faster rate than any other CNA in existence, the harm it's single-handedly caused to the CVE ecosystem hasn't been fully appreciated yet by the public and is mostly relegated to security teams of downstream distributions, vulnerability management companies, and end-users who noticed recently their previously-informative distribution security advisories got replaced with auto-generated lists of hundreds of CVEs with minimal user-understandable/actionable information.
Good! We have environmental CVSS scores now, use them.
No, not good. Just because we have something better doesn't mean it's good to sabotage what most people are still using.
Really.
Related LWN article from one of the kernel team members (Lee Jones):
How kernel CVE numbers are assigned: https://lwn.net/Articles/978711/ (June 19, 2024)
(2024).
Assigning a CVE to every second commit and refusing to assign CVEs to unfixed issues doesn't seem like correct usage of the CVE system. I expect that most Linux CVEs will never get a proper analysis or a CVSS rating.
To me it sounds plausible that the design goal of the Linux CNA is to show that CVEs don't meaningfully apply to the Linux kernel. Given how dependent on context the impact of some kernel bugs can be, if we were assigning CVSS scores for the worst case, practically all kernel bugs would be at least a 9.8/10.
> To me it sounds plausible that the design goal of the Linux CNA is to show that CVEs don't meaningfully apply to the Linux kernel.
I think it's hostile in nature. The core kernel devs have a horrible attitude toward security vulnerabilities.
Yes, my original wording was "to make the CVE system burn", but that got lost during my tone-down edits.
> I expect that most Linux CVEs will never get a proper analysis or a CVSS rating.
You're free to contribute your own analysis and CVSS rating.
No, the problem needs to be fixed. Adding more noise isn't helpful at this point.
Ah, you're paying for some enterprise Linux subscription, then? So that the vendor can on your (and others') behalf influence the kernel devs that they are funding?
What? No, the kernel devs just have stop acting like idiot children in this regard.
Ah, yes, of course!
I hope you're aware this says a lot more about you than it does about kernel devs :)
Honestly, I think your reactions just show that you don't really understand why the kernels devs behavior in this context is so childish and irresponsible.
Looks like you have some reading to do :)
k so I'm writing a blog post on the whole #Linux Kernel #CVE/#CNA thing. And I actually looked at the data. For those of you complaining about the Linux Kernel issuing improper CVEs my response is "cool. If they're not security vulns get them rejected".
So far in 2024 the Linux Kernel error rate is 3.21%.
Is that bad or good?
Let's compare to the top 25 CNA's by error rate for 2024:
f5 49.32%
atlassian 44.44%
Esri 43.75%
freebsd 40.00%
canonical 32.61%
Gallagher 25.00%
SNPS 25.00%
intel 19.74%
Anolis 18.75%
Dragos 18.18%
rapid7 14.29%
@huntr_ai 12.27%
Google 10.00%
directcyber 8.33%
CERTVDE 8.11%
Go 7.69%
lenovo 6.25%
mitre 5.53%
schneider 4.35%
GitHub_P 4.35%
Fluid Attacks 4.35%
Wordfence 3.56%
Linux 3.21%
snyk 2.94%
So... Linux is in at 24th place for error rate. But wait, surely those numbers are skewed towards some smaller CNAs that reject a handful of issues driving up their error rate?
Nope. Several of the mature CNAs like F5, Atlassian, Canonical, Google, Intel, Red Hat, Lenovo, MITRE all issue tens to hundreds to thousands of CVEs a year and have much higher error rates. Actually the worst CNA by raw numbers is MITRE (159).
Spamming this multiple times since people don't seem to read.
Turns out F5 and Intel were just clearing out old reservations, but the other data is correct.
> This oversight meant that in affected kernels with the bad backport [...] not only was the MDS mitigation against the newer attacks turned into a no-op [...]
And this is why we write unit tests folks.