Die Zahl der im Linux-Kernel behobenen Sicherheitslücken nähert sich einem neuen Höchststand. Während über weite Teile der Linux-6.x-Reihe ungefähr 500 CVEs pro Release gezählt wurden, waren es bei Linux 7.0 bereits mehr als 1.000 und bei Linux 7.2 über 1.500. Setzt sich die Entwicklung fort, könnte Linux 7.3 die Marke von 2.000 überschreiten.
Der Anstieg bedeutet nach Angaben der Kernel-Maintainer nicht, dass der Linux-Kernel plötzlich viermal unsicherer geworden ist. Maßgeblich ist vielmehr eine deutlich höhere Fundrate: KI- und LLM-gestützte Werkzeuge durchsuchen inzwischen einen über 40 Millionen Zeilen großen Codebestand, einschließlich alter Treiber und selten verwendeter Komponenten. Sie finden reale Fehler, produzieren aber zugleich Meldungen geringer Priorität, zweifelhafte Patches und Halluzinationen.
Für Betreiber ist deshalb eine wichtige Einschränkung entscheidend: Die Zahl von annähernd 2.000 CVEs ist keine Aussage darüber, dass auf jedem Linux-System 2.000 offen ausnutzbare Lücken vorhanden sind. Die Meldung beschreibt einen projektweiten Prüf- und Wartungsaufwand. Konkrete Betroffenheit hängt weiterhin von Kernel-Version, eingebauten Komponenten, Konfiguration, Hardware und erreichbarer Angriffsfläche ab.
Die Prüfung wird zum eigentlichen Engpass
Wie stark die automatisierte Fehlersuche die Entwicklung belastet, zeigt der Netzwerkbereich von Linux 7.3. Maintainer Jakub Kicinski schätzte, dass zwischen einem Drittel und der Hälfte der 648 im net-next-Zweig bearbeiteten Patches auf KI-getriebene Korrekturen niedriger Priorität, Bereinigungen oder Klarstellungen entfielen. „Wir sind völlig überfordert“, schrieb Kicinski.
Das Problem ist nicht allein die Menge eingereichter Änderungen. Ein automatischer Bericht wird erst dann zu einer belastbaren Sicherheitsmeldung, wenn Menschen den betroffenen Codepfad nachvollziehen, Voraussetzungen prüfen, das Verhalten reproduzieren und einen Patch bewerten. Auch ein technisch korrekter Fund kann praktisch wenig relevant sein, wenn er nur einen alten Treiber betrifft, der auf modernen Systemen weder kompiliert noch geladen wird. Umgekehrt darf ein echter Fehler nicht verworfen werden, nur weil er von einem KI-Werkzeug gefunden wurde.
Dass die Werkzeuge reale Ergebnisse liefern können, ist belegt. In CVE-Einträgen wurden bereits KI-gestützte statische Analysen als Fundmethode genannt; entsprechende Schwachstellen wurden anschließend von Intel Product Security bestätigt. Kernel-Maintainer Greg Kroah-Hartman hat zudem selbst lokal laufende, KI-unterstützte Fuzzing-Werkzeuge erfolgreich zur Fehlersuche eingesetzt. Der Konflikt verläuft daher nicht zwischen menschlicher und automatisierter Analyse, sondern zwischen überprüften Funden und ungefiltertem Output.
Eine hohe CVE-Zahl ist noch keine Risikobewertung
Die aggregierte CVE-Zahl enthält keine gemeinsame Angriffsvoraussetzung und keinen einheitlichen Schweregrad. Für den beschriebenen Trend gibt es weder eine einzelne CVE noch einen gemeinsamen CVSS-Wert, eine pauschal betroffene Version oder eine einzige gepatchte Ausgabe. Ebenso nennen die vorliegenden Angaben keine aktive Ausnutzung, keine beobachtete Angriffskampagne und keinen öffentlichen Exploit, der sich auf die Gesamtheit dieser Funde beziehen würde.
Wie KI-Funde die Kernel-Wartung belasten
Die Grafik zeigt den Weg von der automatisierten Analyse des Linux-Kernels über gemischte Fundqualität und menschliche Prüfung bis zu Patches, Filterung oder der Entfernung alten Codes.
Entsprechend lässt sich aus der Rekordzahl allein keine allgemeine Notfallmaßnahme ableiten. Administratoren sollten weiterhin die Sicherheitshinweise ihrer tatsächlich eingesetzten Distribution oder ihres Kernel-Lieferanten verfolgen, unterstützte Kernel-Stände verwenden und einzelne CVEs anhand der vorhandenen Konfiguration priorisieren. Relevant ist etwa, ob ein betroffener Treiber überhaupt enthalten und geladen ist, ob ein verwundbarer Codepfad erreichbar ist und welche Rechte für eine Ausnutzung erforderlich wären.
Alter Code verliert seinen kostenlosen Bestandsschutz
Die automatisierte Suche verändert zugleich die Rechnung für kaum noch verwendete Kernel-Komponenten. Solange ein alter Treiber wenig genutzt wurde und keine Fehlerberichte erzeugte, verursachte seine weitere Existenz nur begrenzte sichtbare Arbeit. Wenn Fuzzer und KI-Systeme denselben Code regelmäßig untersuchen, muss dagegen jeder plausible Fund geprüft werden – unabhängig davon, wie viele reale Nutzer die zugehörige Hardware noch einsetzen.
Im April wurde deshalb vorgeschlagen, fast 28.000 Zeilen alten Netzwerkcode für Hardware aus der ISA- und PCMCIA-Zeit zu entfernen. Linux 7.3 streicht außerdem alten Treibercode für Systeme von SGI und IBM. Auch der FreeVxFS-Dateisystemtreiber wurde entfernt, nachdem die jahrzehntealte Kompatibilitätsschicht nach Einschätzung ihres Maintainers vor allem noch automatisierten Fehlerprüfern Material lieferte.
Das reduziert Codeumfang und künftige Prüfkosten, beendet aber zugleich Kompatibilität. Betroffen sind vor allem Nutzer sehr alter oder ungewöhnlicher Hardware sowie Spezialinstallationen, die bislang auf historische Kernel-Komponenten angewiesen waren. Für sie kann der Wechsel auf einen neueren Kernel daher funktionale Folgen haben, selbst wenn der entfernte Code sicherheitstechnisch kaum relevant erschien.
Die Kernel-Community filtert KI-Ausgaben mit KI
Die Maintainer reagieren inzwischen auf mehreren Ebenen. Kroah-Hartman untersagte LLM-generierte Patches im Staging-Subsystem grundsätzlich, ausgenommen legitime Sicherheitskorrekturen. Aktualisierte Kernel-Richtlinien warnen zudem davor, ungeprüfte KI-Berichte einzureichen, weil deren Validierung knappe Maintainer-Zeit bindet.
Parallel nutzt die Community selbst mehrere aktuelle KI-Modelle, um Patches zu überprüfen und halluzinierte Ergebnisse auszusortieren. Weitere administrative Routinearbeiten könnten ebenfalls automatisiert werden. Das ist keine vollständige Lösung: Ein Modell, das einen anderen Modelloutput bewertet, ersetzt nicht automatisch Reproduktion, technische Einordnung und verantwortliche Freigabe. Es kann aber den Eingang vorsortieren, bevor jede Meldung dieselbe menschliche Aufmerksamkeit beansprucht.
Linux 7.3 befindet sich bereits in der Testphase; Linus Torvalds veröffentlichte Linux 7.3-rc1 am 30. August nach dem zweiwöchigen Merge-Fenster. Kroah-Hartman will die Entwicklung bei den Kernel Recipes vom 21. bis 23. September 2026 in Paris weiter erläutern.
Mehr Funde verschieben die Kosten der Sicherheit
Die operative Konsequenz der Entwicklung liegt weniger in der Rekordzahl selbst als in der Verteilung der Arbeit. Automatisierte Werkzeuge machen das Finden verdächtiger Stellen billig und skalierbar. Die Kosten für Bestätigung, Priorisierung und saubere Korrekturen bleiben dagegen bei Menschen, deren Zeit nicht im gleichen Maß wächst.
Damit wird Verifikation zur knappen Ressource. Für große Open-Source-Projekte reicht es künftig nicht, immer mehr Fehler zu finden. Sie müssen den Zugang für automatisierte Meldungen so gestalten, dass reproduzierbare Befunde bevorzugt und ungeprüfte Ergebnisse zurückgewiesen werden. Andernfalls verbessert KI zwar die Abdeckung der Fehlersuche, verdrängt aber genau die Maintainer-Arbeit, die aus einem Fund erst ein belastbares Sicherheitsupdate macht.
Jens analysiert seit Jahren digitale Märkte, Preisbewegungen und Plattform-Strategien. Als Betreiber mehrerer datengetriebener Systeme wertet er täglich große Mengen an Produkt- und Trenddaten aus. Sein Fokus liegt auf Einordnung statt Hype: Was bedeutet eine Entwicklung wirklich für Nutzer, Preise und Märkte?
