|
|
Subscribe / Log in / New account

A turning point for CVE numbers

A turning point for CVE numbers

Posted Feb 15, 2024 13:44 UTC (Thu) by farnz (subscriber, #17727)
In reply to: A turning point for CVE numbers by bluca
Parent article: A turning point for CVE numbers

The point is that, because the kernel is a CNA, doing anything with kernel vulnerabilities requires you to either get the kernel team to issue the CVE number, CVSS score etc, or show MITRE that you engaged the kernel team, and they refused to issue a CVE number, attach a CVSS score etc.

A CNA cannot block publication of CVEs in their product, nor can a CNA prevent a CVSS score being attached to a CVE it's responsible for. It just gets "first dibs" on dealing with the issue, but you can still go around them if they're being slow or obstructive. Most of the gain for the kernel is that this blocks the noise, because it blocks the zero-effort CNAs from issuing CVE numbers (or attaching CVSS scores) to a kernel vulnerability. These CNAs are the ones who'd happily issue a CVE for the same vulnerability in the source code once for each supported architecture, or put a 9.8/10.0 CVSS score on a vulnerability because if you have credentials to SSH as root to a host, you can exploit the vulnerability remotely.


to post comments

A turning point for CVE numbers

Posted Feb 16, 2024 10:56 UTC (Fri) by taladar (subscriber, #68407) [Link]

Technically issuing distinct CVE numbers for the same vulnerability on different architectures would actually be useful to the people using the CVE numbers to judge impact, especially if only affected architectures get one. There is nothing worse than a security advisory for an issue you know can't affect you because you are using entirely different hardware (or in the case of non-kernel software entirely different host operating systems) to the one where the problem occurs.


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds