Linux-Kernel-Schwachstellen nach Version: LTS-Zweige

Wie viele CVEs hat mein Linux-Kernel?

Seit dem 13.02.2024 ist das Kernel-Projekt selbst CVE Numbering Authority (CNA) für Linux, die ersten Datensätze erschienen am 20.02.2024. Es veröffentlicht sie im Git-Repository vulns.git auf git.kernel.org. Zu jeder CVE gibt es dort eine Datei mit Endung .dyad: je Zeile die Version, in der der Fehler hineinkam, und die Version, in der die Korrektur in einem Stable-Zweig landete.

Gezählt ist für das neueste Release jedes Zweigs, Stand des Repositorys 03.11.2026: eine CVE ist offen, wenn der fehlerhafte Commit im Release steckt und keine seiner Korrekturen. Zurückgezogene CVEs zählen nicht. Eine zweite Zählung über die Versionsbereiche in den JSON-Datensätzen weicht um weniger als 0,5 % ab.

Die Zahl gilt für den ganzen Quellbaum. Ein Gerät baut davon nur einen Teil, viele Treiber und Subsysteme sind in Ihrer .config gar nicht eingeschaltet. CVEs aus der Zeit vor 2024, die andere Stellen vergeben haben, etwa Dirty Pipe, stehen nicht in diesen Datensätzen und kommen dazu.

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

18217

Wie viel macht der Patch-Stand innerhalb eines Zweigs aus?

Mehr als der Zweig. Ein Kernel, der mit dem Release einer Distribution eingefroren wird, sammelt Monat für Monat offene CVEs: die Stable-Zweige bekommen jede Woche Korrekturen, und für viele davon vergibt das Kernel-Projekt eine Nummer. 6.18.53 enthält 1.252 Commits und schließt laut den Datensätzen 538 CVEs, die in 6.18.52 noch offen sind.

Die Tabelle zeigt Versionen, die Yocto und OpenWrt tatsächlich ausgeliefert haben, neben dem neuesten Release desselben Zweigs. Die KEV-Spalte enthält hier auch ältere Lücken, die nur in der NVD stehen.

Welche Linux-Kernel-Lücken werden aktiv ausgenutzt?

Der KEV-Katalog der CISA (Version 2026.11.03, 1.767 Einträge) führt 32 Lücken unter Hersteller „Linux“, dazu Kernel-Lücken unter „Android“ wie CVE-2024-36971. Zwölf davon haben einen Datensatz des Kernel-Projekts, die übrigen stammen aus der Zeit davor. In jedem gepflegten LTS-Zweig ist auf neuestem Stand keine davon offen. In 5.4, 4.19 und 4.14 bleiben vier, fünf und neun offen, weil die Korrekturen nach dem Ende der Pflege kamen.

$ 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

Welche Kernel-Version liefern Yocto, OpenWrt und Buildroot?

Gelesen an den veröffentlichten Tags, Stand 04.11.2026. Yocto aktualisiert den Kernel in seinen Punkt-Releases, OpenWrt ebenso. Wer ein Punkt-Release nicht nachzieht, bleibt auf dem Stand seines Tags.

Buildroot nimmt als Standard den neuesten Stable-Kernel zum Zeitpunkt des Releases, auch wenn das kein LTS-Zweig ist. 6.19 und 7.1 stehen bei kernel.org nicht mehr in der Liste gepflegter Zweige. Auch Yocto 6.1 hat als Standard 7.2.6, und 7.2 hat am 01.11.2026 mit 7.2.15 sein letztes Release bekommen.

Was ist ein CIP-Kernel, und gelten die Zahlen auch dafür?

Das Civil Infrastructure Platform Project (CIP) pflegt Super-Long-Term-Kernel (SLTS) bis zu zehn Jahre lang, aufbauend auf den LTS-Zweigen: 4.4, 4.19, 5.10, 6.1 und 6.12. Für 6.12 ist die Pflege bis Mitte 2035 angesetzt, für 4.4 bis Januar 2027. Die neuesten Tags am 04.11.2026: v4.4.302-cip115, v4.19.325-cip136, v5.10.272-cip79, v6.1.190-cip62 und v6.12.114-cip34.

Ein CIP-Kernel trägt Korrekturen, die kernel.org im gleichnamigen Zweig nicht mehr ausliefert. Die Zahlen oben gelten für die Releases von kernel.org; in 4.19.325-cip136 stecken zusätzliche Korrekturen. Für einen CIP-Kernel prüfen Sie jede Korrektur am Commit im Quellbaum, siehe unten.

Wo steht die Kernel-Version im Image?

Der Kernel schreibt seine Version als Text in linux_banner, etwa „Linux version 5.10.273 (user@host) (gcc …) #1 SMP …“. Am laufenden Gerät zeigen sie uname -r und /proc/version. Im Dateisystem steht sie im Verzeichnisnamen unter /lib/modules/ und in der vermagic-Zeile jedes Moduls (modinfo).

Im ausgelieferten Image ist der Kernel meist komprimiert (zImage, bzImage, Image.gz), dann findet strings die Zeile erst nach dem Entpacken. Der Quellbaum bringt dafür scripts/extract-vmlinux mit. Ein uImage trägt die Version zusätzlich im Header, standardmäßig als „Linux-<Version>“. Endungen wie -yocto-standard, -cip136 oder die Kennung eines Chip-Herstellers hängen hinter der Versionsnummer.

$ 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";

Wie prüfe ich meinen Kernel von Hand?

1. 1

   Version lesen

   uname -r am Gerät, im Image strings -a vmlinux | grep -m1 "Linux version" nach dem Entpacken.

2. 2

   Herkunft klären

   Release von kernel.org, linux-yocto, CIP oder der Kernel aus dem BSP des Chip-Herstellers. Ab dem Abzweig zählt, welche Korrekturen der Lieferant übernommen hat.

3. 3

   Datensätze holen

   git clone --depth 1 https://git.kernel.org/pub/scm/linux/security/vulns.git. Je CVE nennt die .dyad-Datei Fehler- und Korrekturversion je Zweig.

4. 4

   Zählen

   eine CVE ist offen, wenn die Version mit dem Fehler in Ihrem Kernel steckt und für Ihren Zweig keine Korrektur bis zu Ihrem Patch-Stand eingetragen ist.

5. 5

   Abgezweigte Kernel am Commit prüfen

   git merge-base --is-ancestor <Commit der Korrektur> HEAD im Quellbaum des Lieferanten zeigt, ob eine Korrektur drin ist. Ein Backport trägt eine andere Commit-ID; dann im Log nach dem Titel der Korrektur suchen.

6. 6

   Konfiguration abgleichen

   der JSON-Datensatz nennt die betroffenen Quelldateien (programFiles). Ist der Treiber oder das Subsystem in der .config aus, ist der Code nicht im Image.

7. 7

   Ältere CVEs in der NVD

   mit cpe:2.3:o:linux:linux_kernel:<Version> abfragen und die Bereiche nachlesen. Für CVE-2024-1086 führt die NVD alles vor 5.15.149 als betroffen, die Korrektur ist aber auch in 5.10.210.

8. 8

   KEV-Katalog der CISA

   Einträge mit Produkt „Kernel“ sind aktiv ausgenutzt, unter Hersteller „Linux“ und unter Hersteller „Android“.

Geht das auch automatisch?

LegacyMind liest aus dem Image den Bootloader, den Kernel und die Pakete mit ihren Versionen und gleicht jede gegen die Schwachstellenquellen ab, mit der Fundstelle im Image und dem Vermerk, ob eine Lücke aktiv ausgenutzt wird. Belegt das Image keine Version, bleibt das Feld leer.