Linux kernel vulnerabilities by version: the LTS branches

How many CVEs does my Linux kernel have?

Since 13 February 2024 the kernel project itself has been the CVE Numbering Authority (CNA) for Linux; the first records appeared on 20 February 2024. It publishes them in the Git repository vulns.git on git.kernel.org. For each CVE there is a file ending in .dyad: per line, the version in which the bug came in and the version in which the fix landed in a stable branch.

Counted is the newest release of each branch, repository state of 3 November 2026: a CVE is open if the faulty commit is in the release and none of its fixes is. Rejected CVEs do not count. A second count over the version ranges in the JSON records differs by less than 0.5 %.

The number applies to the whole source tree. A device builds only part of it; many drivers and subsystems are not even enabled in your .config. CVEs from before 2024 that other parties assigned, such as Dirty Pipe, are not in these records and come on top.

$ ls vulns/cve/published/*/*.json | wc -l

18217

How much does the patch level within a branch matter?

More than the branch. A kernel frozen with a distribution release collects open CVEs month after month: the stable branches get fixes every week, and the kernel project assigns a number to many of them. 6.18.53 contains 1,252 commits and, according to the records, closes 538 CVEs that are still open in 6.18.52.

The table shows versions that Yocto and OpenWrt actually shipped, next to the newest release of the same branch. The KEV column here also includes older vulnerabilities that are only in the NVD.

Which Linux kernel vulnerabilities are actively exploited?

The CISA KEV catalogue (version 2026.11.03, 1,767 entries) lists 32 vulnerabilities under vendor “Linux”, plus kernel vulnerabilities under “Android” such as CVE-2024-36971. Twelve of them have a record from the kernel project; the rest date from before. In every maintained LTS branch none of them is open at the newest release. In 5.4, 4.19 and 4.14 four, five and nine stay open, because the fixes came after the end of maintenance.

$ grep -v "^#" vulns/cve/published/2026/CVE-2026-31431.dyad | cut -d: -f1,3

4.14:5.10.254
4.14:5.15.204
4.14:6.1.170
4.14:6.6.137
4.14:6.12.85
4.14:6.18.22
4.14:6.19.12
4.14:7.0

$ grep -v "^#" vulns/cve/published/2026/CVE-2026-53266.dyad | cut -d: -f1,3

5.10:5.10.259
5.10:5.15.210
5.10:6.1.176
5.10:6.6.143
5.10:6.12.94
5.10:6.18.36
5.10:7.0.13
5.10:7.1
5.4.73:0
5.8.17:0
5.9.2:0

Which kernel version do Yocto, OpenWrt and Buildroot ship?

Read at the published tags, as of 4 November 2026. Yocto updates the kernel in its point releases, and so does OpenWrt. Anyone who does not follow a point release stays on the state of their tag.

Buildroot takes as its default the newest stable kernel at the time of the release, even if that is not an LTS branch. 6.19 and 7.1 are no longer in kernel.org's list of maintained branches. Yocto 6.1 also defaults to 7.2.6, and 7.2 got its last release, 7.2.15, on 1 November 2026.

What is a CIP kernel, and do the numbers apply to it?

The Civil Infrastructure Platform project (CIP) maintains super long-term support kernels (SLTS) for up to ten years, built on the LTS branches: 4.4, 4.19, 5.10, 6.1 and 6.12. For 6.12 maintenance is planned until mid-2035, for 4.4 until January 2027. The newest tags on 4 November 2026: v4.4.302-cip115, v4.19.325-cip136, v5.10.272-cip79, v6.1.190-cip62 and v6.12.114-cip34.

A CIP kernel carries fixes that kernel.org no longer ships in the branch of the same name. The numbers above apply to the kernel.org releases; 4.19.325-cip136 contains additional fixes. For a CIP kernel, check each fix by its commit in the source tree, see below.

Where is the kernel version in the image?

The kernel writes its version as text into linux_banner, such as “Linux version 5.10.273 (user@host) (gcc …) #1 SMP …”. On the running device, uname -r and /proc/version show it. In the file system it is in the directory name under /lib/modules/ and in the vermagic line of every module (modinfo).

In the shipped image the kernel is usually compressed (zImage, bzImage, Image.gz); then strings only finds the line after unpacking. The source tree brings scripts/extract-vmlinux for that. A uImage also carries the version in its header, by default as “Linux-<version>”. Suffixes such as -yocto-standard, -cip136 or a chip vendor's identifier follow the version number.

$ curl -s https://raw.githubusercontent.com/torvalds/linux/v6.12/init/version-timestamp.c  \
| grep -n -A2 "linux_banner\[\]"

28:const char linux_banner[] =
29-	"Linux version " UTS_RELEASE " (" LINUX_COMPILE_BY "@"
30-	LINUX_COMPILE_HOST ") (" LINUX_COMPILER ") " UTS_VERSION "\n";

How do I check my kernel by hand?

1. 1

   Read the version

   uname -r on the device, in the image strings -a vmlinux | grep -m1 "Linux version" after unpacking.

2. 2

   Establish the origin

   a kernel.org release, linux-yocto, CIP or the kernel from the chip vendor's BSP. From the branch point on, what counts is which fixes the supplier has taken over.

3. 3

   Fetch the records

   git clone --depth 1 https://git.kernel.org/pub/scm/linux/security/vulns.git. For each CVE the .dyad file names the bug version and the fix version per branch.

4. 4

   Count

   a CVE is open if the version with the bug is in your kernel and no fix up to your patch level is listed for your branch.

5. 5

   Check forked kernels by commit

   git merge-base --is-ancestor <fix commit> HEAD in the supplier's source tree shows whether a fix is in. A backport carries a different commit ID; then search the log for the title of the fix.

6. 6

   Match the configuration

   the JSON record names the affected source files (programFiles). If the driver or subsystem is off in the .config, the code is not in the image.

7. 7

   Older CVEs in the NVD

   query with cpe:2.3:o:linux:linux_kernel:<version> and read the ranges. For CVE-2024-1086 the NVD lists everything before 5.15.149 as affected, but the fix is also in 5.10.210.

8. 8

   The CISA KEV catalogue

   entries with product “Kernel” are actively exploited, under vendor “Linux” and under vendor “Android”.

Can this run automatically?

LegacyMind reads the bootloader, the kernel and the packages with their versions from the image and matches each one against the vulnerability sources, with the location in the image and a note on whether a vulnerability is actively exploited. If the image gives no evidence of a version, the field stays empty.