At Open Source Summit Europe 2026 in Prague I met Greg Kroah-Hartman, who maintains the Linux stable kernels, for a Udienza conversation about kernel sustainability. One topic comes up whenever his name does: the flood of Linux kernel CVEs. Security scanners light up red, compliance teams panic, and someone asks whether Linux suddenly became insecure.
It did not. What changed is who assigns the CVEs and how. This article explains the numbers, and what I recommend production teams do about them.
With Greg Kroah-Hartman in Prague. My notes from that conversation are in Kernel Maintainers in Prague.
The kernel became its own CNA
In February 2024, the Linux kernel project became a CVE Numbering Authority (CNA). Since then, the kernel.org community has been responsible for issuing all CVEs for the Linux kernel itself. Before that, CVEs were assigned by outside parties, inconsistently, and many real fixes never got one.
The kernel CNA’s policy is deliberately cautious: a fix that lands in a stable release and could plausibly be a vulnerability gets a CVE. The reasoning is that, in a kernel, almost any bug can become a security problem depending on how the system is used, and the maintainers cannot know every user’s threat model.
Greg described the result in his December 2025 post Linux CVEs, more than you ever wanted to know: the kernel went “from nothing to number 3 in 2024 to number 1 in 2025” among CVE issuers by volume. New CVEs are published on the linux-cve-announce mailing list.
The numbers
According to Linux CVE Tracker’s statistics:
| Year | Linux kernel CVEs |
|---|---|
| 2024 | about 4,350 |
| 2025 | 5,681 (about 30% more than 2024) |
| 2026 | more than 7,000 by early October |
Of the 2025 CVEs, 47 were rated critical and 1,488 high, and only 3 were confirmed as actively exploited. That ratio is the key to handling the flood: most kernel CVEs are bug fixes that matter to someone, not emergencies for everyone.
The trend will not reverse. As the security keynotes in Prague showed, AI-assisted vulnerability discovery is producing more bug reports across all of open source. The kernel’s CVE count is a measure of how much gets fixed, and that is a good thing.
Why cherry-picking fixes does not work
The traditional enterprise approach is to freeze a kernel version, scan for CVEs, and backport only the ones rated “important”. With thousands of CVEs a year, that breaks down:
- You cannot triage 100+ CVEs a week with a human process, and many arrive without the scores your process expects.
- Fixes depend on each other. Backporting fix 7 of a series without fixes 1–6 creates new bugs. The stable maintainers already did that dependency work for you.
- Severity depends on your use. A bug in a driver you do not load is irrelevant. A bug in a filesystem you rely on may be critical. A generic score cannot tell the difference.
The stable kernel model is the answer the kernel community has given for years: take the whole stable or LTS update, test it, and ship it.
Know your LTS end-of-life dates
Longterm (LTS) kernels get fixes for several years, but not forever. Based on recent reporting on kernel.org’s projections, after support was extended for several branches in 2026:
| LTS branch | Projected end of life |
|---|---|
| 6.18 | December 2028 |
| 6.12 | December 2028 |
| 6.6 | December 2027 |
| 6.1 | December 2027 |
| 5.15 | December 2026 |
| 5.10 | December 2026 |
If you run 5.10 or 5.15 on systems you maintain yourself, you have about two months of upstream fixes left. Check kernel.org’s releases page for the current dates before you plan.
Enterprise distributions such as RHEL, SUSE and Ubuntu LTS maintain their own kernels with their own lifecycles. If you use a vendor kernel, follow the vendor’s errata stream instead, but apply the same principle: take the vendor’s full updates rather than picking individual fixes.
What I recommend
- Run a supported stable or LTS kernel, or a supported vendor kernel. Nothing else scales.
- Update on a schedule, not per CVE. A monthly or bi-weekly kernel update with a test pipeline is less risky than ad-hoc patching.
- Make kernel updates boring. Immutable, image-based hosts make updates and rollbacks routine. I covered that in The OS Layer in the AI Era and in bootc for immutable Linux.
- Filter by what you actually run. Use your kernel configuration and loaded modules to prioritise CVEs that touch code you ship.
- Prepare for the CRA. The EU Cyber Resilience Act brings vulnerability handling obligations for products with digital elements, and Greg spent much of 2025 working on how the CRA applies to open source. If your product embeds Linux, a documented update process is now a compliance requirement. See my notes on CRA SBOM requirements and my interview on CRA defaults with Daniel Thompson-Yvetot.
The bigger picture
At 35 years old, Linux is fixed faster and more transparently than ever. The CVE numbers are uncomfortable because they make that work visible. The teams that suffer are the ones still trying to patch a 2026 kernel with a 2010 process.
For the rest of my Prague coverage, see Open Source Summit Europe 2026: Complete Prague Guide.
