How kernel CVE numbers are assigned

Some early CVE announcements raised questions both on the mailing lists and off. The Linux CNA Team has received messages of firm support, particularly from those dedicating significant time to Linux security. Other messages, largely received from distributors and teams that look after enterprise platforms and attempt to remain stable yet secure by taking the fewest changes possible, have reflected some concern. Some of the stronger points raised were about how the rise in the number of CVEs would increase workload and overwhelm security teams attempting to review them all. Others have suggested that consumers of CVEs at the distribution and enterprise level, particularly those charging for this service, should have been reviewing all stable commits for fixes to relevant security flaws all along. One independent, security-related maintainer was particularly taken aback that paid-for distributions were not reviewing additional stable fixes beyond those identified as CVE candidates as they should have been.

Whichever side of the fence contributors sit on, one thing is almost universally agreed upon: for a plethora of reasons, the old CVE process wasn't working well. LWN listed many of the major points in this recent article. An additional point that deserves attention is that many downstream maintainers (myself included to a point, although Android did have the additional safety net of regular merges from the long-term-support stable kernels) were content with the strategy of cherry-picking all relevant CVEs raised and calling it good in terms of ongoing security updates. This practice, of course, would lead to a false sense of security, since it misses hundreds of security-related fixes and ultimately results in less-secure kernels.

The new process is more exhaustive and aims to identify every commit that fixes a potential security issue. Some people have mentioned that they consider this strategy to be a little overzealous, however since we started this endeavor back in February, it has only resulted in 863 allocations out of the 16,514 commits between v6.7.1 and v6.8.9. That's a mere 5% hit rate.

Negative opinions have been exacerbated by historical thoughts shared by Kroah-Hartman and others, and by a misunderstanding of the current literature. In an article about a 2019 Kernel Recipes talk, Kroah-Hartman is paraphrased as saying: "The next, option, 'burn them down', could be brought about by requesting a CVE number for every patch applied to the kernel." In truth, the plan was never to create a flood of CVE numbers to overwhelm the current system such that it would eventually be abandoned, nor has that come close to becoming a reality. The Linux CNA Team is careful to keep CVE assignments to a minimum, only assigning numbers to flaws that pose a possible risk to security.

Unfortunately, some of the phrases in the documentation haven't helped much to quell these fears. For instance, this section is often quoted:

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.

This section is often misunderstood or taken too literally. The part concerning assigning CVE numbers to "any bugfix", should be expanded to say "any bugfix relevant to the kernel's security posture". For instance, a fix repairing a broken LED driver would never be sensibly considered for assignment. That said, prescribing the exact types of issues that are considered is a slippery slope. A recent attempt at doing so was submitted to security@kernel.org for pre-review and was promptly rejected by the group. However, a non-exhaustive list of considerations I look for are bugs like buffer overflows, data corruption, crashes (BUGs, oopses and panics, including those affected by panic_on_warn), use-after-frees (UAF), lock-ups, double frees, denial of service (DoS), data leaks, etc.

One question that crops up from time to time can be summarized as: "why are we so overzealous and why can't we only create CVEs for severe security fixes?"; the answer is that quality assessment is an impossible task. Since the kernel is infinitely configurable and adaptable, it's not possible to know all the ways in which it could be deployed and utilized. Evaluating potential vulnerabilities and associating generic levels of bug reachability, severity, and impact is infeasible. An unreachable vulnerability on one platform may be trivial to exploit on another. Even if a particular issue could be proven to be universally low-risk, it might still be used as a stepping stone in a more involved, chained attack. For all these reasons and more, we find the most sensible approach is to assume that "security bugs are just bugs" and assign any issue with possible security-related ramifications.

The Linux CNA Team does not take the process of allocating CVE numbers lightly and the process is not automated. Over the first full release (6.7.y), the process consisted of all three members of the team (Greg Kroah-Hartman, Sasha Levin, and myself) manually reviewing every single patch hitting stable and voting on each. If a commit obtained three positive votes, it was allocated a CVE number. Commits with two votes were subjected to a second review, followed by discussion.

The team members review candidates in various ways. One utilizes Mutt in exactly the same way as they would review mainline patch submissions, another is in the process of training a machine-learning (ML) model to identify hard-to-spot issues, and I prefer to use Git output piped through a helper tool that highlights telltale words and phrases for easy "yes" votes. "No" votes take more time to review. The current thinking is that, by using different tools and methods, our positive results would be more robust; at least that's the theory.

Once CVEs are created, they are submitted to the linux-cve-announce mailing list, where interested parties are able to review them at their leisure. The engineers at SUSE deserve a lot of credit here. They have been instrumental in highlighting allocations that ended up being duplicate CVEs raised by previous CNAs in a non-searchable way, or ones that did not merit a CVE assignment. Their input helped shape the way the team now conducts analysis. Anyone is free and even encouraged to review the linux-cve-announce list and respond to CVEs they consider invalid. If the team agrees with the evaluation, the CVE assignment will be promptly rejected. Since the start of this endeavor, 65 such instances have occurred.

Hopefully this helps to clear up some of the current misconceptions in terms of the methods used to review, identify, and process CVE candidates and allays some of those fears people have been communicating to me recently. Specifically, CVE numbers are not assigned in an automated manner, and they are only assigned to bugs that might reasonably be believed to have security implications. The team remains open to constructive feedback and genuine suggestions for improvements; it is committed to its responsibilities and exercises care and due diligence during all phases of the process. If you have any questions or suggestions for us, then you can use the contact details located in the kernel's Documentation/process/cve.rst file. We'd be happy to hear from you.