Skip to content

Linux 7.3-rc4 bringt von LLMs gefundene Fehlerpfad-Fixes

Linux 7.3-rc4 erschien am 20. September 2026, die Korrekturen zu je einem Drittel in Treibern, Dateisystemen und Architekturcode. Torvalds lobt LLMs.

Von Tech AI Wire Team

4 Min. Lesezeit

XLinkedIn
A laptop on a desk showing a code editor with a colored diff, beside a coffee mug and a closed notebook.

Die Zahlen

of the rc4 fixes that sit in drivers
1/3
Btrfs bugs fixed in this prepatch
2
when the silent data-loss bug was introduced
2023

Linus Torvalds hat am 20. September 2026 Linux 7.3-rc4 freigegeben und dabei große Sprachmodelle als nützliche Quelle für eine ganz bestimmte Art von Fehlerbericht hervorgehoben. Phoronix zitiert ihn mit der Aussage, dass "verschiedene LLMs offenbar ziemlich gut darin sind, etwas zu finden" - gemeint sind Probleme im Aufräumcode von Fehlerpfaden. Das ist eine eng gefasste Aussage des ranghöchsten Kernel-Betreuers und interessanter als ein gewöhnlicher Prepatch.

Ein Prepatch, auch Release Candidate genannt, ist ein wöchentlicher Testbau, während eine Kernel-Version stabilisiert wird. Torvalds nannte diesen laut LWN "groß" und fügte hinzu, das sei zu diesem Zeitpunkt im Zyklus nicht überraschend.

Warum LLMs ausgerechnet Fehlerpfade finden

Das Aufräumen in Fehlerpfaden ist eine bekannte Schwachstelle in C-Code, und der Kernel ist voll davon. Eine Funktion nimmt eine Sperre, reserviert Speicher, holt eine Referenz auf ein Objekt - und scheitert mittendrin. Alles bisher Geholte muss in umgekehrter Reihenfolge freigegeben werden, bevor die Funktion zurückkehrt.

Der erfolgreiche Weg durch eine solche Funktion wird ständig ausgeführt. Die Fehlerwege laufen im Normalbetrieb oft gar nicht. Ein Leck oder eine vergessene Freigabe kann dort jahrelang sitzen, ohne dass es jemandem auffällt.

Diese Form erklärt auch, warum ein Modell solche Fehler findet. Der Fehler ist lokal und in einer einzigen Funktion sichtbar: Etwas wurde geholt und nicht freigegeben. Wer das prüft, muss das ganze Teilsystem nicht verstehen, und ein Modell muss das ebenso wenig. Es ist Mustererkennung gegen eine Regel, die der Kernel überall anwendet.

Das ist eine weit bescheidenere Behauptung als die, Modelle könnten Kernel-Code schreiben. Torvalds beschreibt eine Fehlerklasse, bei der die nötige Schlussfolgerung flach und die Codemenge riesig ist. Genau diese Kombination beherrschen automatische Werkzeuge seit jeher gut.

Was sonst in rc4 steckt

Phoronix berichtet, die Korrekturen verteilten sich etwa gleichmäßig in Drittel: rund ein Drittel in Treibern, ein Drittel in Dateisystemen und Netzwerkcode, ein Drittel in Architektur- und Werkzeugcode.

BereichBerichtete Beispiele
ArchitekturKorrekturen für x86 und x86_64
DateisystemeZwei Btrfs-Fehler sowie Änderungen an SMB und NTFS
TreiberNeue Unterstützung für den XPad-Spielecontroller

Eine Korrektur sticht heraus. Phoronix berichtet von einem Patch für einen Fehler, der stillschweigend Daten aus dem User Space verlor, und davon, dass der Defekt seit 2023 bestand. Stiller Datenverlust ist die schlimmste Sorte Kernel-Fehler, weil zum Zeitpunkt des Verlusts nichts sichtbar fehlschlägt und der Schaden erst später auffällt, wenn überhaupt.

Die Btrfs-Arbeit setzt einen Strang aus diesem Zyklus fort: Zuvor waren Korrekturen für Dateisystem-IDs und den grub2-Start für genau diesen Prepatch vorgemerkt. Die finale Version von Linux 7.3 ist für Oktober 2026 geplant.

Was das für Entwickler bedeutet

Nehmen Sie die LLM-Aussage in der Größe, in der sie gemacht wurde. Torvalds nannte das Aufräumen in Fehlerpfaden, nicht Korrektheit allgemein. Wer das Ergebnis nachstellen will, richtet ein Modell auf die eigenen Fehlerpfade. Stellen Sie ihm eine eng gefasste Frage: Gibt jeder vorzeitige Rücksprung das frei, was die Funktion oberhalb geholt hat?

Vergleichen Sie es mit dem, was Sie ohnehin einsetzen. Der Kernel nutzt für diese Fehlerklasse seit vielen Jahren statische Analyse, etwa mit Coverity und smatch. Interessant ist nicht, ob Modelle Fehlerpfad-Fehler finden, sondern ob sie solche finden, die jene Werkzeuge übersehen, und mit welcher Rate an Fehlalarmen. Darauf antwortet keiner dieser Berichte, also bleibt es eine offene Frage statt eines entschiedenen Erfolgs.

Wichtiger als der Fund ist der Weg der Meldung. Ein Modell erzeugt einen plausibel aussehenden Patch ebenso leicht wie einen echten, und ein Betreuer erkennt den Unterschied nur, wenn er die Prüfung selbst vornimmt. Wenn Sie einen so gefundenen Fix einreichen, prüfen Sie ihn zuerst selbst und schreiben Sie dazu, wie Sie ihn gefunden haben. Halten Sie den Patch klein genug, dass er in einem Durchgang prüfbar ist.

Wer 7.3 verfolgt, bekommt hier das übliche Signal zum Testen. Torvalds nannte diesen Kandidaten groß, ohne ihn beunruhigend zu nennen. An diesem Punkt im Zyklus steht die Gestalt der Freigabe fest, und die restlichen Wochen dienen dem Feinschliff. Wer Module außerhalb des Baums oder einen Distributionskernel pflegt, sollte jetzt gegen rc4 bauen, statt auf die Oktober-Freigabe zu warten. Ubuntu 26.10 liefert bereits einen Vorabkernel 7.3 aus, einige Nutzer treffen diesen Code also vor der finalen Version.

Der Datenverlust-Fehler von 2023 ist die praktische Mahnung dieser Freigabe. Ein Defekt, der Nutzerdaten still verwirft, überlebte drei Jahre in einem Kernel, den mehr Menschen lesen als fast jede andere Codebasis. Das spricht für mehr automatische Prüfung jener Pfade, die niemand ausführt, egal welches Werkzeug sie am Ende übernimmt.

Quellen

  1. Kernel prepatch 7.3-rc4 - LWN.net
  2. Linux 7.3-rc4 Released: More Fixes Caught By LLMs, But Nothing Too Scary - Phoronix

Ähnliche Artikel