Raghu Bharadwaj

Posted on Aug 31 Originally published at techveda.live

Kernel CVEs Per Release Have Tripled. The Bugs Have Not.

#linux #kernel #security #embedded

A chart published on 28 August shows kernel CVEs per release climbing from roughly 500 to beyond 1,500 since Linux 7.0. Read carelessly it says the kernel is getting less safe. The stable maintainer confirmed in the same thread that the axis counts CVEs fixed, not introduced, which makes the rise a measure of how much better the tooling has become at finding old bugs. The number that should worry an embedded team is a different one he mentioned in passing: the release that introduced the most CVEs is 5.15, a longterm kernel still shipping in products today.

A kernel CVE chart went around at the end of last week and was widely read as bad news. The shape is genuinely dramatic — a long flat stretch at about 500 CVEs per release, then a step up past a thousand, then past fifteen hundred, with the next release plausibly breaking two thousand. If you ship a Linux product and someone forwarded you that chart, the question you were asked was probably some version of "is the kernel falling apart?" The answer is no, and the reason is in the axis label rather than the curve.

What the chart actually measures

The chart came from Greg Kroah-Hartman, who runs the stable trees and the kernel's CVE assignment team, as a teaser for a talk he is giving at Kernel Recipes in Paris in September. It plots CVEs per release from 6.9 through 7.2. Reading the plot: the 6.9 to 6.19 range sits at roughly 500 per release, every release from 7.0 onward is above one thousand, and 7.2 passes fifteen hundred.

In the replies, someone asked the question that decides what the chart means — is this CVEs fixed, or CVEs found in newly added code? The answer was one word: "Fixed."

That single word inverts the story. A rising count of fixed vulnerabilities in a codebase of roughly 40 million lines is not evidence that the code is getting worse. It is evidence that more of what was already there is being found. A second reply in the same thread made the limitation explicit: the chart shows discovery and fixing, but not how long each flaw sat in the tree being exploitable. Greg Kroah-Hartman also confirmed that longterm kernels are where these fixes actually land, and that the chart does not attempt to show that, because kernel releases form a graph rather than a single line in time.

His own explanation for the jump was dry rather than alarmed — that it looks as though some tools recently got better at finding bugs.

The corroborating numbers

A chart on a slide is one data point, and a kernel CVE story should not rest on one. The independent development statistics for 7.2 show the same inflection from a completely different direction, counting commits rather than CVE identifiers.

The 7.2 release contains 4,830 commits carrying Fixes tags, meaning commits that repair a bug introduced by an earlier commit. Plotted across releases, the count of commits with Fixes tags is roughly level for many releases and then rises sharply at the right-hand edge — the same shape, from a measurement that has nothing to do with CVE assignment. The analysis attributes it to the same cause: large numbers of people pointing language models at the task of finding bugs in existing software.

That analysis also carries a caution worth repeating. There is a crossover point around 5.9 where the kernel appears to start fixing more bugs than it introduces, but that conclusion is not stable, because it takes years for the bugs introduced in any given release to be found. Every year that passes moves the line.

One more figure sets the scale of what is coming. Around 14,000 non-merge changesets were queued in linux-next for 7.3, and more than 1,100 of them carry an Assisted-by tag. That is a lower bound on machine involvement, since it counts only the contributors who declared it.

Why the kernel CVE count is high by policy

There is a second reason the numbers look extreme, and it has nothing to do with tooling. It is written into the kernel's own CVE policy, and most people quoting CVE counts have not read it.

The kernel became its own CVE Numbering Authority so that assignment would be controlled by the people who understand the code. The policy document is blunt about the consequence. Because the kernel sits at a layer where almost any bug might be exploitable, and because exploitability is usually not evident at the time a bug is fixed, the assignment team is deliberately over-cautious and assigns a CVE number to any bugfix it identifies — which, in the document's own words, explains the seemingly large number of CVEs the kernel team issues.

Two further rules in that policy matter for anyone doing kernel CVE triage on a product. No CVE is assigned for an issue found in a kernel version that the stable team is not actively supporting, so a count of assigned CVEs tells you nothing about a kernel that fell off the supported list. And the policy states plainly that applicability is the user's problem, not the assignment team's.

The number that actually matters for embedded products

Buried in a reply, and absent from the coverage, is the figure that should change what an embedded team does this week. Asked for a chart of CVEs introduced per release rather than fixed, Greg Kroah-Hartman declined to publish one before the talk but gave away the result: 5.15 leads as the release that created the most CVEs, and he offered no explanation for why.

Take that seriously for a moment. 5.15 is not a historical curiosity. It is one of the longterm kernels listed as maintained on kernel.org, and it is still the base for a large number of shipping embedded products, because vendor board support packages have long lifetimes and 5.15 was the default choice for several silicon generations.

Two qualifications keep that honest. First, "most CVEs created" is partly a function of how much attention a release has received and how long it has been available to analyse, so it is not a clean quality ranking. Second, those bugs are fixed in the 5.15 stable series as they are found — that is exactly what the stable process does. The conclusion is not that 5.15 is unsafe. It is that a 5.15 product which is not tracking the stable series closely is accumulating known, fixed-upstream defects faster than a product on any other longterm base.

What the published CVE data does and does not tell you

Published kernel CVE counts are a different measurement again, on a different denominator, and mixing them with per-release counts produces nonsense. Counting by publication date from the national vulnerability database rather than by kernel release, 2026 has 5,061 kernel CVEs published so far. The monthly distribution is wildly uneven:

Month, 2026	Kernel CVEs published
January	246
February	220
March	178
April	379
May	1,034
June	514
July	838
August (partial)	1,652

Those swings are mostly publication batching rather than real changes in discovery rate, which is the first reason not to build a metric on this series. Of the 5,061, some 1,033 are still awaiting a severity score, so a fifth of the year's kernel CVEs have no CVSS number at all. And exactly two of them appear in the catalogue of vulnerabilities confirmed as being exploited in the wild.

Hold those two numbers next to each other. Thousands of assigned identifiers, two confirmed exploited. That gap is not a scandal and it is not a reason to ignore CVEs. It is the direct, expected result of a policy that deliberately assigns an identifier to every bugfix that might conceivably have security relevance. A process that treats every kernel CVE as an incident will spend all its time on the wrong ones.

What to do about it on your product

The volume is not going to fall soon, so the practical response is to stop treating the count as the signal. Three things are worth doing this week.

First, find out whether you are even receiving the assignments. They are announced on a dedicated mailing list, and the archive is public, so a team that has been reading vendor advisories has probably been getting a filtered and delayed view:

raghu@techveda.org:~$ uname -r
6.6.155
raghu@techveda.org:~$ curl -s https://lore.kernel.org/linux-cve-announce/ | head

Second, confirm your base kernel is still one the stable team supports, because no kernel CVE will be assigned against a version that is not. A product on an unsupported base does not have fewer vulnerabilities; it has fewer identifiers pointing at them:

root@imx8mp-evk:~# uname -r
5.15.219
root@imx8mp-evk:~# cat /proc/version | cut -c1-60
Linux version 5.15.219 (oe-user@oe-host) (aarch64-poky-l

Check that version against the maintained list on kernel.org rather than against your vendor's release notes. The two disagree more often than teams expect, and the vendor's number is frequently a branch name rather than a supported stable version.

Third, change the question your triage process asks. The official policy already tells you the answer will not come from upstream: applicability is yours to determine, because upstream does not know which subsystems you build. A kernel CVE in a driver you do not compile is not a finding. The tractable version of the work is to derive the set of subsystems your configuration actually enables, and filter against that before anything else:

root@imx8mp-evk:~# zcat /proc/config.gz | grep -c '=y'
1847
root@imx8mp-evk:~# zcat /proc/config.gz | grep -cE '^CONFIG_.*=m'
312

That count is the real scope of your exposure, and it is a small fraction of the tree the CVE numbers are drawn from. The policy also makes the uncomfortable recommendation explicit: it is better to take all released stable changes as a tested whole than to cherry-pick individual fixes, because many problems are only resolved by the sum of several changes, and some relevant fixes never get a CVE at all. A team cherry-picking only CVE-tagged commits is running a strategy the upstream documentation advises against.

What I could not verify

The per-release figures in this article — roughly 500, then above 1,000, then above 1,500 — are readings of a chart. I did not independently recount CVEs per kernel release, and the underlying per-release data has not been published yet; the full set is being held for the talk in September. Treat the shape as well supported, since an independent Fixes-tag analysis produces the same inflection, and treat the individual values as approximate.

I also found no public explanation for why 5.15 leads on CVEs created. The maintainer explicitly said he did not know, and I am not going to supply a theory he declined to offer.

Key takeaways

The chart counts kernel CVEs fixed per release, not introduced. The maintainer confirmed this directly.
An independent count of commits carrying Fixes tags — 4,830 in 7.2 — shows the same sharp rise, so the trend is real even if the exact per-release values are approximate.
The kernel CVE team assigns an identifier to any bugfix that might have security relevance, by policy. High counts are the intended outcome, not a symptom.
5.15 leads as the release that introduced the most CVEs, and it is still a maintained longterm kernel widely used in embedded products.
Of 5,061 kernel CVEs published in 2026 so far, two are confirmed as exploited in the wild and about a fifth have no severity score at all.
No CVE is assigned against an unsupported kernel version, so an old base looks quiet without being safe.
Upstream states that applicability is the user's call and that taking whole stable releases beats cherry-picking individual CVE fixes.

References

I teach Linux kernel, device driver and embedded Linux engineering at TECH VEDA. If your team is working through kernel CVE triage or choosing an LTS base for a product, that is the kind of thing we cover in the Linux kernel and BSP programmes.

DEV Community