Linux kernel publishes 432 CVEs in two days: what it really says about kernel security

The Linux kernel security team publishes 432 CVEs in 48 hours. A spectacular raw figure, but it needs to be put into perspective: it is the direct consequence of the CNA policy adopted in 2024.

Facts

The Linux kernel security team publishes 432 CVEs in two days - a peak that fuels alarmist headlines and mailing list discussions. The figure itself is indisputable, but its interpretation requires context.

Since February 2024, the Linux project has become a CNA (CVE Numbering Authority) with MITRE. This means that the kernel team can now assign CVE identifiers to its security fixes themselves, without going through a third party. Direct result: the pace of CVE publication has skyrocketed, not because the kernel is suddenly less secure, but because every fix that could have a security impact now receives a CVE by default.

Who is affected (and how to read this figure)

Three categories must be distinguished in this mass of CVEs:

1. Real vulnerabilities exploitable remotely or in LPE - those that justify an immediate patch. They remain a minority in the flow.
2. Theoretical vulnerabilities in exotic subsystems - rarely compiled drivers, code for little-deployed architectures (SH, PA-RISC, IA-64 before withdrawal). CVE valid in theory, operational impact close to zero for 99% of installations.
3. Precautionary fixes - race conditions, use-after-free difficult to trigger, minor information leaks. To be corrected, but not emergencies.

The kernel's CNA policy, defended by Greg Kroah-Hartman, is explicit: any fix that touches security is a CVE, and it is up to users (distributions, companies) to sort out what concerns them. This is a reversal of responsibility compared to the era "we call CVE what is already exploited" - more intellectually honest, but which produces these peaks in figures.

The rising angle: bug reports assisted by AI?

The subtitle of The Register's coverage of the affair is explicit: the peak "fuels speculation about AI-assisted bug reports". The idea has been circulating on kernel lists for several months: the democratization of tools that run smart fuzzing and static analysis enhanced by LLM produces bug reports in a continuous flow, and part of these reports (the true positives) ends up in fixes that, under the CNA policy, become CVEs.

At this stage, nothing is officially confirmed on the kernel team's side. The move to broad CNA is more than enough to explain the raw figure, without needing to invoke an AI factor. But the question is worth asking: if tomorrow a significant portion of CVEs is produced by AI tools, should the ecosystem treat these reports differently (dedicated channel, mandatory human review before CVE, explicit marking in descriptions)? The debate is not resolved.

What to do now

Analysis

The bottom line is an old debate in open source security: what level of granularity for vulnerability disclosure?

The old model ("we only talk about real exploited vulnerabilities") had the advantage of readability, and the defect of creating an artificially low CVE noise floor - companies believed their kernel was "clean" while dozens of security bugs went under the radar each month.

The new model (broad CNA) makes reality visible, but unusable raw for most teams. Mediation becomes the work of distributions and patch management tools, not that of the end user.

An honest figure to keep in mind: the Linux kernel fixes approximately 1,800 to 2,500 bugs per month in stable branches. The fraction that affects security is structurally significant - the kernel is a 30+ million line C monster, a good part of it in little-audited driver code. That CVE publication reflects this reality is healthy; that it gives the impression of a fire is not.

To remember

• 432 CVEs in 2 days = consequence of the kernel's CNA policy, not of a security collapse.
• A hypothesis of "AI-assisted reports" circulates to explain the peak - not confirmed at this stage.
• Follow the advisories of your distribution, not the kernel's raw flow.