On Thu, Feb 15, 2024 at 01:10:55PM +0100, Greg Kroah-Hartman wrote: > +Note, due to the layer at which the Linux kernel is in a system, almost > +any bug might be exploitable to compromise the security of the kernel, > +but the possibility of exploitation is often not evident when the bug is > +fixed.
By this paranoid black-and-white logic, any mainline commit could have a yet-to-be-discovered regression resulting in a catastrophic vulnerability. Should we stay one step ahead and just open a CVE for every mainline commit? Problem solved, all "vulnerabilities" have been identified! False positives be damned! For that matter, why don't we do as Thomas has suggested and hardcode NR_CPUS to zero! > Because of this, the CVE assignment team is overly cautious and > +assign CVE numbers to any bugfix that they identify. This > +explains the seemingly large number of CVEs that are issued by the Linux > +kernel team. How does this match up with the definition of a vulnerabilty? An instance of one or more weaknesses in a Product that can be exploited, causing a negative impact to confidentiality, integrity, or availability; a set of conditions or behaviors that allows the violation of an explicit or implicit security policy. Bug != vulnerability. Otherwise the definition of a vulnerability would be much simpler, i.e., "any software defect". If a CVE is created without any analysis and doesn't describe how the bug can be exploited then it's completely useless. Who is this process helping? - Not users of -stable since they already know they need to be on the latest version. - Not distros or their users as it's just flooding them with low quality CVEs which have no analysis or scoring. And enterprise distros will never be able to rebase onto -stable, especially for older streams for which they have to be very selective, in order to avoid destabilizing them. As you say, "a bug is a bug". If the problem is low CVE quality then of course it makes a lot of sense for kernel.org to become a CNA in order to take a leadership role in helping define and improve the process for its users. But it makes no sense to "fix" it by making CVE quality *vastly* lower by flooding people with useless CVEs. -- Josh
