CVE-2026-45920 in Linux
Zusammenfassung
von VulDB • 27.05.2026
Im Linux-Kernel wurde folgende Schwachstelle behoben:
ext4: Behebung der doppelten Dekrementierung von dirtyclusters beim Herunterfahren des Dateisystems
Der fstests-Test generic/388 reproduziert gelegentlich eine Warnung in ext4_put_super(), die mit der Zählung der dirty clusters (verschmutzte Cluster) verbunden ist:
WARNING: CPU: 7 PID: 76064 at fs/ext4/super.c:1324 ext4_put_super+0x48c/0x590 [ext4]
Die Nachverfolgung des Fehlers zeigt, dass die Warnung aufgrund eines s_dirtyclusters_counter-Werts von -1 ausgelöst wird. Das heißt, es handelt sich hierbei offenbar um eine irreführende Dekrementierung im Gegensatz zu einer Art von Speicherleck. Eine weitere Nachverfolgung der Delta-Werte der dirty-cluster-Zählung und eine LLM-Scan (Large Language Model) der daraus resultierenden Ausgabe identifizierten die Ursache als eine doppelte Dekrementierung im Fehlerpfad zwischen ext4_mb_mark_diskspace_used() und dem aufrufenden Element ext4_mb_new_blocks().
Zunächst ist anzumerken, dass generic/388 ein Test für Herunterfahren im Vergleich zu fsstress ist und daher eine zufällige Menge an Operationen und Herunterfahr-Injektionen erzeugt. Im problematischen Fall löst das Herunterfahren eine Fehler-Rückgabe aus dem Aufruf von ext4_handle_dirty_metadata() aus, der von ext4_mb_mark_context() aufgerufen wird. Der geänderte Wert ist zu diesem Zeitpunkt nicht null, daher verlässt ext4_mb_mark_diskspace_used() die Funktion nicht, nachdem der Fehler von ext4_mb_mark_context() nach oben durchgereicht wurde. Stattdessen dekrementiert die erstgenannte Funktion beide Cluster-Zähler und leitet den Fehler an ext4_mb_new_blocks() weiter. Letztere fällt in den !ar->len-Ausweg, der den dirty-clusters-Zähler ein zweites Mal dekrementiert, was die Inkonsistenz erzeugt.
Um dieses Problem zu vermeiden und die Verantwortung für die Cluster-Reservierung in diesem Codepfad zu vereinfachen, wird die Reduzierung des Zählers an eine einzige Stelle im aufrufenden Element gehoben. Dies macht klarer, dass ext4_mb_new_blocks() für das Erwerben der Cluster-Reservierung (über ext4_claim_free_clusters()) im !delalloc-Fall sowie für das Freigeben verantwortlich ist, unabhängig davon, ob sie verbraucht wird oder aufgrund eines Fehlers zurückgegeben wird.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.