Auf dem Linux Kernel Maintainers Summit im Dezember 2025 in Tokio stand das Thema »Wie gehen wir mit KI um?« prominent auf der Agenda. Kernel-Entwickler Sasha Levin diskutierte dort Richtlinien für den Einsatz von ML-Tools und LLMs in der Kernel-Entwicklung. Einigkeit herrschte darüber, dass menschliche Verantwortung für Patches zentral bleibt, rein maschinell erzeugte Beiträge unerwünscht sind und die Tool-Nutzung offengelegt werden sollte.
Im April 2026 wurden die Ergebnisse der Diskussion in eine neue Richtlinie gegossen, die KI-unterstützte Code-Beiträge explizit erlaubt, vorausgesetzt, die Entwickler halten strenge neue Transparenzregeln ein. Mittlerweile sind die neuen Richtlinien auch Teil der Kernel-Dokumentation.
Zu viele mehrfache Meldungen
Allerdings scheinen nicht allzu viele mit Sicherheit und KI befasste Kollegen das zu lesen, denn Linus Torvalds nahm die Veröffentlichung von Linux 7.1-rc4 zum Anlass, sich zu beschweren, dass die private Kernel-Mailingliste für Sicherheit security@kernel.org derzeit von mit KI-Tools entdeckten Bugs überschwemmt werde und fast nicht mehr zu handhaben sei. Das liegt daran, dass viele Sicherheitsforscher die gleichen Bugs mit den gleichen Tools finden und diese somit gleich mehrfach gemeldet werden.
Das liegt daran, dass es sich bei security@kernel.org um eine interne, geschützte Adresse nur für die Kernel‑Security‑Officers handelt und nicht jeder die Einträge lesen kann. Somit wissen die Sicherheitsforscher nicht, dass ein Bug vielleicht bereits mehrfach gemeldet wurde.
Don’t be the drive-by ‘send a random report with no real understanding’ kind of person. OK?
Linus Torvalds
Dokumentation lesen
Torvalds bezeichnet dies als »sinnloses Geschwätz« und gänzlich kontraproduktiv. KI-Tools seien ein gutes Hilfsmittel, aber nur, wenn sie hilfreich eingesetzt werden. Wer wirklich einen Mehrwert schaffen will, soll zunächst die Dokumentation lesen. Das anschließende Erstellen eines Patches würde dem, was die KI geleistet hat, noch einen echten Mehrwert hinzufügen.
GKH positiv überrascht
Noch zu Beginn des Jahres schloss das Curl-Projekt sein Bug-Bounty-Programm, weil die Entwickler mit KI-Slop überschwemmt wurden. Greg Kroah-Hartman, die Nummer 2 der Kernel-Entwicklung, zeigte sich dagegen in einem Interview mit The Register Ende März positiv überrascht, dass KI-Tools in den vergangenen Monaten enorm dazugelernt haben und derzeit kaum noch KI-Slop abliefern. Aber wenn positive Bugreports durch mehrfaches Einreichen die Bearbeitung erschweren, läuft trotzdem etwas falsch.
Foto von Steve A Johnson auf Unsplash
Torvalds schreibt:
“AI detected bugs are pretty much by definition not secret, and treating them on some private list is a waste of time for everybody involved – and only makes that duplication worse because the reporters can’t even see each other’s reports.”
Ein Vorgehen, das nicht ganz unkritisch gesehen werden kann, denn Sicherheitslücken incl. exploids werden auf diese Weise öffentlich und damit ausnutzbar.
Wie meinst du das? Auf der Liste kann man Bugs einreichen, aber die anderen Einreichungen nicht lesen. Deshalb gibt es so viele doppelte und dreifache Meldungen. Ich sehe jetzt nicht, wie etwas dadurch öffentlich wird.
Ich interpretiere Linus dahingehend, dass alles was die AI findet, incl. Sicherheitslücken als öffentlich anzusehen ist und als regulärer bug report eingereicht werden soll, was dabei hilft Duplikate zu vermeiden.
Das wäre eine nicht ganz unkritische Änderung der bisherigen Praxis, wobei man auch sehen muss, dass die bisherige Praxis, die Veröffentlichung zurückzuhalten bis gepatcht ist, bei AI ohnehin nicht mehr funktioniert.
Das kann ich da nicht rauslesen.