Anyone watching security alerts for a Linux server has seen it: dozens of new kernel CVEs every week, many of them reading like ordinary bug fixes. That isn’t an illusion. Since the project became a CVE Numbering Authority (CNA) in February 2024, the team that assigns identifiers has followed a deliberately broad policy, and the numbers have soared.
Why the kernel became a CNA
A CNA is an organisation authorised by the CVE Program to assign identifiers for vulnerabilities in its own scope. Before 2024, any outside CNA (a vendor, or a researcher going through MITRE) could file a CVE against the kernel without involving its developers. The official process document, Documentation/process/cve.rst, is blunt about it: kernel CVEs “were very often assigned in inappropriate ways and for inappropriate reasons”, and “ongoing abuses by individuals and companies outside of the kernel community” made it clear the project itself should control those assignments.
Greg Kroah-Hartman, who runs the stable branches, announced it on his blog on 13 February 2024 in a post titled “Linux is a CNA”. He writes that he thinks the CVE system is “broken in many ways”, but sees the change as a way to take responsibility and get ready for the laws that are starting to require open source projects to handle their vulnerabilities. He points to curl and Python as projects that did the same for the same reasons.
Since then, the documentation says that a CVE assigned by anyone else against a supported kernel version should not be treated as valid, and that only the maintainers of the affected subsystem can dispute or modify one.
A CVE for almost every fix
The key is one paragraph in cve.rst. Because of where the kernel sits in a system, “almost any bug might be exploitable to compromise the security of the kernel”, but that is rarely obvious when the bug is fixed. So the team is “overly cautious” and assigns a CVE to any bugfix that they identify. The document itself admits this explains “the seemingly large number of CVEs”.
A few other rules are worth knowing:
- CVEs are assigned only once the fix is in a stable kernel, and are tracked by the original commit. No CVEs for unfixed bugs, unless someone asks for a reserved one at
[email protected]. - No CVEs for versions the stable/LTS team no longer maintains. Right now that means 7.3 plus the 6.18, 6.12, 6.6, 6.1, 5.15 and 5.10 longterm branches, per kernel.org.
- Bugs that exist only in a distribution’s patched kernel belong to that distribution, not the kernel CNA.
- Whether a CVE applies to a given system is up to the user. In the document’s words: “we do not know your use case, and we do not know what portions of the kernel that you use”.
Every assignment goes out on the linux-cve-announce list and is recorded in the vulns.git repository on kernel.org.
The numbers, counted from the repository
The repository keeps one set of files per published CVE under cve/published/: the JSON record, the announcement sent to the list and a .dyad file listing which versions introduced and fixed the bug. Counting when each record entered the git history (data as of 2 November 2026, only records still published):
| Year | CVEs published |
|---|---|
| 2024 (from February) | 4,287 |
| 2025 | 5,675 |
| 2026 (to 2 November) | 8,228 |
| Total | 18,190 |
Another 324 were rejected after assignment. The 2026 pace is nearly double the previous year’s, with August (1,643) and September (2,112) the busiest months on record; the repository doesn’t say why. Counting by the year in the identifier rather than the publication date gives 3,064 CVE-2024, 2,667 CVE-2025 and 7,971 CVE-2026 entries, plus 4,488 with 2019–2023 identifiers that cover older fixes catalogued after the fact, mostly during 2024.
The criticism and the impact on distributions
The practical problem is plain. Many compliance tools and vulnerability scanners treat every CVE as something to review, document and close. With hundreds of announcements a month, an enterprise security team can’t analyse them one by one, and distributions with long-term kernels have to work out which ones affect their versions. For a long time the CNA’s records carried no severity score either, so every distribution had to compute its own.
That last part has partly changed: since April 2026 the repository has a tool for assigning CVSS 3.1 scores, and 6,562 published CVEs now have a .cvss file with the reasoning behind each metric.
The kernel team’s position hasn’t moved: apply all the fixes in a stable release, because they’re tested together, rather than cherry-picking individual patches. The document adds that some relevant fixes may have no CVE at all, because the team doesn’t always spot them.
How sysadmins should cope
- Follow your distribution’s stable or LTS kernel and update on its schedule. That’s what the kernel itself recommends: take the whole release instead of judging CVE by CVE. Distribution advisories, such as Ubuntu’s kernel USNs, already do that filtering for you.
- Save individual analysis for what matters: bugs with public exploits, or ones in components you actually run. Cases like Copy Fail or Dirty Frag deserve immediate attention and sometimes a temporary mitigation.
- Use the tools in
vulns.git.bippygenerates the JSON records and announcements, anddyadworks out the vulnerable/fixed version pairs from a commit; they’re more useful for understanding a record than for daily work. To check a specific version,strakis handier: it lists the CVEs still unfixed at a given commit or release.cve_searchmaps a commit to its CVE and back. All of them need a local clone of the stable kernel tree. - Turn off what you don’t use. Many CVEs hit drivers or protocols a server never loads; blacklisting those modules genuinely shrinks the attack surface.
Supported kernel versions and their dates are on the Linux kernel page.
Sources: Documentation/process/cve.rst; the kernel CNA’s vulns.git repository (our own count as of 2 Nov 2026); linux-cve-announce archive; “Linux is a CNA” by Greg Kroah-Hartman; supported releases on kernel.org.