CVE-2026-43158 in Linux
Zusammenfassung
von VulDB • 25.05.2026
Im Linux-Kernel wurde folgende Schwachstelle behoben:
xfs: Korrektur der Freemap-Anpassungen beim Hinzufügen von xattrs zu Leaf-Blöcken
xfs/592 und xfs/794 lösen beide diese Assertion im Code zur Freemap-Anpassung von Leaf-Blöcken aus, nachdem sie etwa 20 Minuten lang auf meinen Test-VMs ausgeführt wurden:
ASSERT(ichdr->firstused >= ichdr->count * sizeof(xfs_attr_leaf_entry_t) + xfs_attr3_leaf_hdr_size(leaf));
Nachdem ich deutlich mehr Debugging-Code aktiviert hatte, konnte ich das Problem auf fsstress eingrenzen, der versuchte, eine lokale erweiterte Attribut (xattr) mit namelen=3 und valuelen=71 festzulegen. Dies führt zu einer Eintragsgröße von 80 Bytes.
Zu Beginn von xfs_attr3_leaf_add_work sieht die Freemap wie folgt aus:
i 0 base 448 size 0 rhs 448 count 46 i 1 base 388 size 132 rhs 448 count 46 i 2 base 2120 size 4 rhs 448 count 46 firstused = 520
wobei „rhs“ das erste Byte nach dem Ende des Leaf-Eintrags-Arrays ist. Dies ist inkonsistent – das Eintrags-Array endet bei Byte 448, aber freemap[1] besagt, dass freier Speicher ab Byte 388 beginnt!
Am Ende der Funktion ist die Freemap noch schlechter aufgestellt:
i 0 base 456 size 0 rhs 456 count 47 i 1 base 388 size 52 rhs 456 count 47 i 2 base 2120 size 4 rhs 456 count 47 firstused = 440
Wichtiger Hinweis: 388 ist nicht mit der Elementgröße des Eintrags-Arrays von 8 Bytes ausgerichtet.
Basierend auf der fehlerhaften Freemap beginnt der Name-Bereich bei Byte 440, was unterhalb des Endes des Eintrags-Arrays liegt! Genau das ist der Grund, warum die Assertion auslöst und das Dateisystem heruntergefahren wird.
Wie sind wir hier gelandet? Erinnern wir uns zunächst an das vorherige Patch: Das Freemap-Array in einem xattr-Leaf-Block ist nicht dazu gedacht, eine umfassende Karte des gesamten freien Speicherplatzes im Leaf-Block zu sein. Mit anderen Worten, es ist völlig legal, einen Leaf-Block mit folgenden Eigenschaften zu haben:
* 376 Bytes werden vom Eintrags-Array belegt * freemap[0] hat [base = 376, size = 8]
* freemap[1] hat [base = 388, size = 1500]
* der Speicherplatz zwischen 376 und 388 ist frei, aber die Freemap hat dies vor einiger Zeit nicht mehr verfolgt
Wenn wir ein xattr hinzufügen, wächst das Eintrags-Array auf 384 Bytes, und freemap[0] wird zu [base = 384, size = 0]. Bisher ist alles in Ordnung. Wenn wir jedoch ein zweites xattr hinzufügen, wächst das Eintrags-Array auf 392 Bytes, und freemap[0] wird auf [base = 392, size = 0] verschoben. Dies ist problematisch, da freemap[1] nicht aktualisiert wurde, und nun beanspruchen das Eintrags-Array und der freie Speicher denselben Bereich.
Die Korrektur hier besteht darin, alle Freemap-Einträge so anzupassen, dass keiner von ihnen mit dem Eintrags-Array kollidiert. Beachten Sie, dass diese Korrektur auf dem Commit 2a2b5932db6758 („xfs: fix attr leaf header freemap.size underflow“) und dem vorherigen Patch basiert, der Freemap-Einträge mit Länge 0 auf base = 0 zurücksetzt.
If you want to get best quality of vulnerability data, you may have to visit VulDB.