Security patching in the Linux kernel has changed abruptly. For years, releases moved along at around 500 fixed CVEs; today the number is approaching 2,000, with Linux 7.3 potentially breaking that threshold. The stated cause is not a sudden collapse in code quality, but the spread of LLM models able to analyze the kernel's vast codebase and flag a growing number of potential vulnerabilities.

This acceleration deserves a counterintuitive reading: more CVEs does not automatically mean a less secure system. A significant part of the phenomenon comes from greater observational capacity, not from a proportional increase in real defects. LLMs lower the cost of finding interesting candidates, but they do not reduce the cost of verifying, fixing, and shipping patches. The bottleneck therefore shifts from discovery to management.

The bottleneck is no longer discovery

When the number of CVEs per release grows fourfold, the informational value of each individual report also changes. Hundreds of CVEs can be handled one by one; thousands force automated prioritization, filters, and triage. For kernel maintainers, this means more time separating real problems from false positives and low-impact reports. For distributions and long-term support kernel providers, the load multiplies: every CVE must be assessed, possibly backported, and tested across multiple branches.

The structural point is that LLMs reduce the marginal cost of discovery, but the marginal cost of remediation remains tied to human work and integration cycles. In an ecosystem like the Linux kernel, where trust is built through incremental review, the asymmetry between discovery and fixing can lengthen the queue of known but unresolved vulnerabilities.

The bill for self-hosted infrastructure operators

Those who run self-hosted Linux servers, including machines used for local model inference, receive this pressure in the form of more frequent security patches. The choice between applying a fix immediately and delaying it to avoid disrupting a workload becomes more frequent. In on-premise contexts, direct control over the platform also carries the operational cost of vulnerability management: more CVEs mean more maintenance, more regression testing, and more maintenance windows.

This dynamic does not eliminate the advantages of self-hosting, but it makes them more explicit. For those evaluating on-premise deployment of LLM stacks, the patching load is one factor to include in TCO and data sovereignty calculations. AI-RADAR offers analytical frameworks at /llm-onpremise to compare these trade-offs, without reducing the choice to a simple technology preference.

Approaching 2,000 CVEs per release may look like an indicator of insecurity. In reality, it signals that automated analysis capacity is outpacing the absorption capacity of the development process. The open question is not whether LLMs will find more bugs, but whether the kernel ecosystem can turn this wave of reports into effective fixes without paralyzing maintainers.