Numbers are climbing, but the kernel isn’t getting worse
Stable kernel maintainer Greg Kroah-Hartman surfaced a striking data point in a public slide deck: the number of CVEs fixed per Linux 7.x release has jumped from “over 1,000” in 7.1 to “over 1,500” in 7.2, with 7.3 on track to break 2,000. Tom’s Hardware and Solidot picked up the numbers almost simultaneously, with two independent outlets cross-confirming the figures.
The more interesting question is the causal explanation Kroah-Hartman attaches: the Linux kernel has not become less secure. What changed is that AI-assisted security scanning tools have flooded in, sweeping across roughly 40 million lines of source code and dumping every “low-severity” defect they can find into CVE databases and mailing lists.
The real cost: too many reports, not enough hands
On paper, automated tools surfacing more bugs sounds like progress. In practice, the Linux kernel’s maintainer headcount has not scaled with the report volume. Floods of reports pour into Bugzilla, mailing lists, and patchwork, and the actual triage, reproduction, and fix work multiplies faster than the maintainers can absorb.
Jakub Kicinski, who maintains the kernel’s networking subsystem, used the phrase “completely overwhelmed” in the related discussion, and Tom’s Hardware lifted that phrase straight into its headline. A handful of humans being drowned by machine-generated reports is, in itself, a new shape of AI-era software engineering: detection capability grows exponentially, while human digestion and decision capacity barely moves.
The awkward part is that most of the newly surfaced bugs are low-severity, not real security grenades. Yet maintainers are legally and ethically obligated to investigate each one — that is the deal under GPL-style coordinated disclosure, and it is also what downstream vendors and distributions require. Every report must be seen, acknowledged, and dispositioned, or it becomes a public-relations problem of its own.
7.3 is already “deleting code” to stop the bleeding
According to Kroah-Hartman’s slides and the Solidot write-up, Linus Torvalds and the subsystem maintainers have adopted a strikingly aggressive tactic for the 7.3 cycle: directly removing “barely used” legacy driver code to shrink the surface AI tools can scan.
7.3 has already dropped a batch of old SGI and IBM drivers. The reasoning is blunt: those long-frozen, sparsely-maintained code paths are exactly where AI tools are most efficient at finding bugs, and the maintainers have no appetite to keep fixing hardware nobody runs. Leaving the code in only deepens the “report flood.”
It is a deeply instrumental choice: rather than spend human cycles validating thousands of machine-generated suspicious reports, simply delete the code that produces them. “Subtractive maintenance” of this kind is rare in Linux kernel history, and in some sense it represents AI tools pushing back, in reverse, against the open-source collaboration model.
Reflection: has AI detection actually made the world safer?
The explosion of AI-assisted security scanning tools is reshaping the maintenance cost structure of every large open-source project. A corner-case bug that might have lain dormant for a decade can now be surfaced in seconds by GPT-style or specialized static-analysis models, which then auto-generate CVE entries, auto-write emails, and auto-track patch status. In the short term that looks like the “democratization of security research.” In the medium to long term, it pushes maintenance costs up to a level only the biggest commercial-backed projects can afford. The Linux kernel gets by because LWN, the Software Freedom Conservancy, Intel, Red Hat, Huawei, and others collectively fund dozens of full-time maintainers — and even then they are barely keeping up with the report flood. An ordinary open-source project would simply grind to a halt.
Kroah-Hartman putting these numbers on a public slide deck is, in that light, less a warning than a nudge to the whole open-source community: when AI drives the cost of “finding a bug” to near zero, “verifying and fixing a bug” becomes the new bottleneck. What the ecosystem now needs is not just better detection models, but stronger triage tooling, automated reproduction and verification, and durable funding mechanisms for the infrastructure underneath. Otherwise 7.x will be followed by 8.x, and the CVE numbers will only keep climbing.
References: