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.
4 Min. Lesezeit

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.
| Bereich | Berichtete Beispiele |
|---|---|
| Architektur | Korrekturen für x86 und x86_64 |
| Dateisysteme | Zwei Btrfs-Fehler sowie Änderungen an SMB und NTFS |
| Treiber | Neue 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
Ähnliche Artikel

Linux-7.4-Patch öffnet Dateien im Test 39% schneller
Ein 43-zeiliger Patch für Linux 7.4 entfernt zwei überflüssige Dentry-Referenzen beim Öffnen einer Datei und hebt einen 20-Kern-Benchmark um 39%.

Linux 7.3 repariert Btrfs-Dateisystem-IDs und grub2-Start
Eine Btrfs-Änderung in Linux 7.2-rc1 machte Dateisystem-IDs instabil und brach die Schlüsselableitung von OpenConnect. Der Fix berührt 10 Dateien.

Linux 7.2.6 führt einen Stable-Schub mit 9.000 Patches an
Greg Kroah-Hartman hat sieben Stable-Kernel auf einmal veröffentlicht, mit mehr als 9.000 Patches zusammen und über 1.800 allein in Linux 7.2.6.