LWN documents the dramatic scale of the increase — hundreds of CVEs per month versus dozens previously — and traces it directly to the kernel team becoming its own CNA in early 2024. The analysis frames this as a policy shift (assigning CVEs to essentially every security-relevant bug fix) rather than a change in code quality.
The editorial argues this is a textbook case of Goodhart's Law: organizations that equated CVE count with risk level are now getting false signals because the denominator changed. The kernel didn't get less secure — the reporting threshold simply dropped to capture fixes that were previously committed quietly without CVE assignments.
The kernel security team's longstanding argument is that every kernel bug is potentially a security bug, making selective CVE assignment arbitrary. By taking on CNA status and assigning CVEs broadly, they ensure downstream consumers — enterprise distros, embedded vendors — can no longer miss security-relevant fixes hidden in routine stable branch updates.
The editorial highlights that enterprise security teams, compliance auditors, and vendor risk platforms all consume CVE feeds. When dashboards light up red due to a process change rather than actual increased risk, procurement teams ask uncomfortable questions and Linux deployments get flagged as higher-risk — causing concrete business friction despite no change in software quality.
The Linux kernel security team has been issuing CVEs at a pace that would have been unthinkable two years ago. After the kernel project became its own CVE Numbering Authority (CNA) in early 2024, the volume of kernel-related CVE reports climbed sharply — and it hasn't stopped. LWN.net's latest analysis documents the scale of this increase, with the kernel now generating hundreds of CVEs per month where it previously generated dozens.
The backstory matters. Before the kernel team took on CNA responsibilities, kernel security fixes were often committed quietly. A bug would be found, patched, merged into stable branches, and — unless it was particularly severe — no CVE was ever assigned. The kernel's own security process, run by Greg Kroah-Hartman and others, explicitly argued that *every* bug in the kernel is potentially a security bug, making individual CVE assignments somewhat arbitrary. The shift to CNA status meant the kernel team now assigns CVEs to essentially every bug fix that could have security implications, a policy that massively expanded the count without changing the underlying code quality.
This isn't a theoretical concern. Enterprise security teams, compliance auditors, and vendor risk platforms all consume CVE feeds. When the Linux kernel suddenly shows a steep upward trend line in vulnerability reports, dashboards light up red. Procurement teams ask uncomfortable questions. Security reviews flag Linux deployments as higher-risk — all because a *process* changed, not because the software got worse.
The kernel CVE surge is a case study in Goodhart's Law applied to security metrics: when a measure becomes a target, it ceases to be a good measure. Organizations that built workflows around "CVE count = risk level" are now getting burned by a denominator change they didn't anticipate.
The Hacker News discussion (291 points as of this writing) reveals a community split. One camp argues this is unambiguously good: more CVEs means better tracking, which means faster patching, which means improved security posture. The transparency argument is straightforward — silent fixes help no one except attackers who read git logs more carefully than defenders do.
The opposing camp raises a practical objection: signal-to-noise ratio. When a kernel stable release comes with dozens of new CVEs attached, and your compliance tooling requires you to assess each one, the operational burden on downstream consumers is real. Distribution maintainers (Red Hat, SUSE, Canonical, Android) have to triage, backport, and release updates against a firehose of advisories. For teams without dedicated kernel security engineers, the volume is paralyzing — they can't distinguish the critical memory-corruption bug from the theoretical race condition in a driver they don't use.
Greg Kroah-Hartman has been characteristically direct about this: the kernel's position is that you should run the latest stable kernel, period. If you're backporting individual fixes based on CVE severity scores, you're doing it wrong. The CVE flood is, in part, a forcing function — an argument that cherry-picking security fixes from stable branches was always a losing strategy, and now the numbers make that obvious.
There's also a meta-problem with CVSS scoring. Many of the new kernel CVEs receive scores that don't reflect real-world exploitability because the CVSS framework wasn't designed for an operating system kernel where "local access" means something very different depending on your threat model. A container escape is existential for a cloud provider and irrelevant for an embedded device. The flat scoring system obscures this.
If you run Linux in production (so, basically everyone): audit how your organization consumes kernel CVE data. If your vulnerability management platform auto-generates tickets for every kernel CVE, you're about to drown — or you already are. The practical move is to shift from CVE-count-based policies to a combination of: (1) running the latest stable kernel from your distribution, (2) filtering CVEs by subsystem relevance to your actual hardware and workload, and (3) treating the kernel team's stable release cadence as your primary patching signal rather than individual CVE advisories.
If your compliance framework mandates response to every CVE above a CVSS threshold, you need to have a conversation with your auditors now. The kernel's CVE volume under the new CNA model makes a per-CVE response policy untenable at scale. Some organizations are already negotiating exemptions or switching to a "latest stable kernel" attestation model instead.
If you maintain a Linux distribution or embedded product: the backporting calculus has fundamentally changed. The kernel team's implicit message is clear — stop maintaining your own fork of security patches and move to tracking stable releases more closely. The cost of evaluating each CVE for backport-worthiness now exceeds the cost of just taking the stable update. This is a bitter pill for teams with heavily customized kernels, but the math doesn't lie.
If you build security tooling: this is a signal to rethink how you present kernel vulnerability data. Raw CVE counts are now actively misleading as a risk metric for the Linux kernel. The tools that add value will be the ones that contextualize — filtering by subsystem, by actual exploitability, by relevance to the user's specific kernel configuration. Vendors who just relay NVD data without kernel-specific context are generating noise, not security.
The kernel CVE flood isn't going to recede. If anything, as the CNA process matures and more historical fixes get retroactive CVE assignments, the numbers will keep climbing. This is a permanent shift in how kernel security information is structured. The organizations that adapt — by updating their tooling, their compliance frameworks, and their patching strategies — will be fine. The ones that keep treating CVE count as a proxy for risk are going to spend the next year in triage hell, chasing numbers that were never meant to be a scorecard.
>software that used to follow the "release-then-go-back-to-cave" model will have to change to start dealing with maintenance for real, or to just stop being proposed to the world as the ultimate-tool-for-this-and-that because every piece of software becomes a target.Actually, some softw
>people will finally understand that security bugs are bugs, and that the only sane way to stay safe is to periodically update, without focusing on "CVE-xxx"The problem is that the very same tools, I expect, are behind the supply chain attacks that seem to be particularly notorious rece
The last paragraph is interesting: "Overall I think we're going to see a much higher quality of software, ironically around the same level than before 2000 when the net became usable by everyone to download fixes. When the software had to be pressed to CDs or written to millions of floppie
Important to note that this is a comment on this article: https://lwn.net/Articles/1065586/.
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.
> people will finally understand that security bugs are bugs, and that the only sane way to stay safe is to periodically update, without focusing on "CVE-xxx"Linux devs keep making that point, but I really don't understand why they expect the world to embrace that thinking. You don