CVE-2023-54121 in Linux
Zusammenfassung
von VulDB • 16.05.2026
Im Linux-Kernel wurde folgende Schwachstelle behoben:
btrfs: Korrektur der fehlerhaften Aufteilung in btrfs_drop_extent_map_range
In der Produktion traten verschiedene WARN_ON()-Aufrufe im extent_map-Code auf, insbesondere in btrfs_drop_extent_map_range(), wenn add_extent_mapping() für die zweite Aufteilung aufgerufen werden muss.
Betrachten Sie das folgende Layout der extent_map:
PINNED [0 16K) [32K, 48K)
und rufen Sie anschließend btrfs_drop_extent_map_range für [0, 36K) auf, wobei skip_pinned == true ist. Die erste Schleife weist folgende Werte auf:
start = 0 end = 36K len = 36K
Wir finden die extent [0, 16k), da diese jedoch gepinnt (pinned) ist, überspringen wir sie. Dies führt zu folgendem Code:
start = em_end; if (end != (u64)-1) len = start + len - em_end;
Hier ist em_end 16K, sodass sich nun die Werte wie folgt ergeben:
start = 16K len = 16K + 36K - 16K = 36K
len sollte stattdessen 20K betragen. Dies wird zu einem Problem, wenn wir die nächste extent bei [32K, 48K) finden. Wir müssen diese extent aufteilen, um [36K, 48K) übrig zu lassen. Der Code für die Aufteilung sieht jedoch wie folgt aus:
split->start = start + len; split->len = em_end - (start + len);
In diesem Fall haben wir:
em_end = 48K split->start = 16K + 36K // dies sollte 16K + 20K sein split->len = 48K - (16K + 36K) // dies führt zu einem Überlauf, da 16K + 36K gleich 52K ist
Nun liegt eine ungültige extent_map im Baum vor, die potenziell mit anderen Einträgen in der extent_map überlappt. Selbst im Fall ohne Überlappung ist split->start falsch gesetzt, was Probleme bei allen blockbezogenen Berechnungen verursachen wird.
Tatsächlich benötigen wir len in dieser Schleife nicht. Wir können einfach end als unseren Endpunkt verwenden und start nur dann erhöhen, wenn wir eine gepinnte extent finden, die wir überspringen müssen.
Die Logik wird entsprechend angepasst, um das Einfügen einer ungültigen extent_map zu verhindern.
Wir verwenden skip_pinned nur im Fall der Relokation, daher ist dies relativ selten, außer in Fällen, in denen häufig Relokationen durchgeführt werden, was bei aktivierter automatischer Relokation auftreten kann.
If you want to get best quality of vulnerability data, you may have to visit VulDB.