Linus Torvalds sieht die private Sicherheitsliste des Linux-Kernels durch massenhaft eingereichte KI-Fehlerberichte stark überlastet. In der Ankündigung von Linux 7.1-rc4 vom 17. Mai 2026 beschreibt Torvalds eine Flut aus Berichten mit hoher Dopplung. Viele Einsendungen stammen offenbar aus denselben oder sehr ähnlichen KI-Werkzeugen. Der Fall trifft einen zentralen Bereich der Linux-Entwicklung, denn Sicherheitsmeldungen binden direkt die Zeit von Kernel-Maintainern. Torvalds schreibt, die Sicherheitsliste sei durch die fortlaufende Welle aus KI-Berichten nahezu unverwaltbar geworden. Maintainer müssten viele Meldungen nur noch an die zuständigen Personen weiterleiten oder erklären, ein Problem sei bereits vor Wochen oder Monaten behoben worden. Das eigentliche Ziel der privaten Liste gerät dadurch aus dem Blick. Sie soll kritische Sicherheitsprobleme koordinieren, nicht öffentlich erkennbare Standardfehler mehrfach sortieren.
Warum KI-Berichte die Sicherheitsliste belasten
Der Kern des Problems liegt nicht in KI-Werkzeugen allein. Torvalds kritisiert vor allem den Umgang mit deren Ergebnissen. Wenn mehrere Personen dieselben Tools auf denselben Kernel-Code ansetzen, entstehen schnell identische Funde. Eine private Liste verschärft diese Lage, weil Einreicher die Meldungen anderer Personen nicht sehen. Dadurch entstehen weitere doppelte Berichte mit fast identischem Inhalt.
Nach Torvalds sind per KI entdeckte Fehler in vielen Fällen nicht geheim. Ein breit verfügbarer Scanner oder ein verbreitetes Sprachmodell kann denselben Befund an vielen Orten erzeugen. Eine Behandlung über eine vertrauliche Sicherheitsliste kostet dann Zeit, ohne zusätzliche Sicherheit zu schaffen. Besonders problematisch sind Berichte ohne Verständnis für den betroffenen Code. Sie erzeugen Aufwand für Maintainer, liefern aber keinen Patch, keinen geprüften Reproducer und keine belastbare Einschätzung der Auswirkungen.
Die aktuelle Diskussion kommt zu einem Zeitpunkt mit spürbar mehr KI-Einsatz in Open-Source-Projekten. Greg Kroah-Hartman hatte im März erklärt, KI-gestützte Berichte seien zuletzt deutlich nützlicher geworden. Das steht nicht zwingend im Widerspruch zu Torvalds. Ein echter Fund kann trotzdem eine Belastung sein, wenn er mehrfach, zu lang, schlecht formatiert oder ohne getesteten Lösungsvorschlag eingeht.
Neue Regeln für KI-gestützte Kernel-Berichte
Die offizielle Kernel-Dokumentation enthält nun klarere Hinweise zu Sicherheitsmeldungen und zum verantwortungsvollen Einsatz von KI. Der Sicherheitskanal ist für dringende Fehler gedacht. Ein solcher Fehler muss einem Angreifer auf einem korrekt konfigurierten Produktionssystem neue Fähigkeiten geben und leicht ausnutzbar sein. Normale Kernel-Bugs gehören in die öffentlichen Meldewege. Ein KI-gestützter Fund soll grundsätzlich als öffentlich behandelbar gelten, sofern er durch allgemein verfügbare Werkzeuge leicht erneut auftauchen kann.
Gleichzeitig warnt die Dokumentation vor einem unbedachten öffentlichen Teilen von Reproducer-Code. Reporter sollen in solchen Fällen nur erwähnen, dass ein Reproducer vorhanden ist. Maintainer können ihn bei Bedarf privat anfordern. KI-Berichte sollen außerdem kurz, als reiner Text und ohne Markdown-Dekoration eingereicht werden. Wichtig sind betroffene Kernel-Versionen, Dateien, Funktionen, reproduzierbare Schritte und eine überprüfbare Einschätzung der Auswirkungen.
Torvalds fordert von Einreichern einen zusätzlichen Beitrag über den reinen KI-Fund hinaus. Wer per KI einen Fehler findet, soll die Dokumentation lesen, einen Patch erstellen und diesen testen. Ein Bericht ohne Verständnis für das Problem gilt in der Kernel-Community zunehmend als Belastung. Die neue Linie schließt KI nicht aus. Sie verschiebt die Verantwortung klar zurück zu den Menschen hinter den Einsendungen.
Für Nutzer ändert sich zunächst wenig, denn die Debatte betrifft vor allem den Entwicklungsprozess des Linux-Kernels. Für Administratoren, Distributionen und Sicherheitsforscher ist sie dennoch relevant. Der Linux-Kernel steckt in Servern, Desktops, Android-Geräten, Routern und vielen eingebetteten Systemen. Wenn Maintainer weniger Zeit mit doppelten KI-Meldungen verlieren, bleiben mehr Ressourcen für echte Sicherheitslücken, stabile Patches und schnelle Rückmeldungen an die zuständigen Subsysteme.