CVE-2026-89493
Zusammenfassung
von VulDB • 12.09.2026
Im Linux-Kernel wurde folgende Schwachstelle behoben:
ocfs2: Validierung von rl_used gegen rl_count im Refcount-Block-Validator
ocfs2_find_refcount_rec_in_rl() durchläuft das on-disk Refcount-Datensatz-Array mit:
for (; i rf_records.rl_used); i++) {
rec = &rb->rf_records.rl_recs[i];
...
rl_recs[] befindet sich in einem einzelnen Metadatenblock (4096 Bytes bei der gängigen Konfiguration), sodass seine tatsächliche Kapazität durch ocfs2_refcount_recs_per_rb(sb) festgelegt ist (247 Datensätze für einen 4K-Block mit dem 16-Byte großen ocfs2_refcount_rec). rl_used und rl_count werden von ocfs2_validate_refcount_block() direkt von der Festplatte gelesen, jedoch vor jedem Refcount-/Reflink/CoW-Vorgang, der das Array durchläuft, weder gegen diese Kapazität noch gegeneinander überprüft.
Ein gefälschter (oder beschädigter) Refcount-Block mit rl_used == 0xffff lässt die obige Schleife weit über das Ende des Blocks hinauslaufen und dereferenziert rl_recs[i] für i bis zu 65534. Der resultierende Index wird dann an den geschwisterlichen Aufruf ocfs2_insert_refcount_rec() weitergegeben, dessen Einfüge-Verschiebung (insert-shift) Folgendes ausführt:
if (index < rf_list->rl_used)) memmove(&rf_list->rl_recs[index + 1],
&rf_list->rl_recs[index],
(le16_to_cpu(rf_list->rl_used) - index) * sizeof(struct ocfs2_refcount_rec));
d. h., ein memmove() von bis zu (0xffff - index) * 16 Bytes (~1 MiB) ab einem Offset, der bereits hinter dem Block liegt. Dies ist über einen normalen Reflink (FICLONE) gegen ein gefälschtes/beschädigtes ocfs2-Image erreichbar: Das Anhängen einer Extent, deren cpos nach jedem echten Datensatz im Blatt sortiert wird, zwingt die Suche dazu, bis zum Ende zu laufen, anstatt bei einem Treffer frühzeitig zurückzukehren. Das Angreifermodell ist lokal: CAP_SYS_ADMIN beim Einbinden eines gefälschten oder beschädigten ocfs2-Images oder ein Raw-Write auf das Blockgerät, das ein bereits eingebundenes ocfs2-Dateisystem unterstützt.
ocfs2_validate_refcount_block() validiert zwar die ECC-Signatur des Blocks, rf_blkno und rf_fs_generation, überprüft jedoch niemals rl_count/rl_used gegen die tatsächliche on-disk-Kapazität des Blocks. Dies ist dieselbe Art von Lücke, die ocfs2_validate_extent_block() (fs/ocfs2/alloc.c) bereits für den geschwisterlichen Extent-Listen-Header schließt, der sowohl die Datensatzkapazität als auch die "used"-Grenze überprüft, bevor Code h_list.l_recs[] durchläuft:
if (le16_to_cpu(eb->h_list.l_count) != ocfs2_extent_recs_per_eb(sb)) {
rc = ocfs2_error(...); goto bail; }
if (le16_to_cpu(eb->h_list.l_next_free_rec) > le16_to_cpu(eb->h_list.l_count)) {
rc = ocfs2_error(...); goto bail; }
Fügen Sie die äquivalente Paarung von Prüfungen zu ocfs2_validate_refcount_block() hinzu: Lehnen Sie einen Refcount-Block ab, dessen rl_count nicht mit der festen pro-Block-Kapazität übereinstimmt, die von ocfs2_refcount_recs_per_rb() zurückgegeben wird, und lehnen Sie rl_used > rl_count ab. Beide Prüfungen werden übersprungen, wenn OCFS2_REFCOUNT_TREE_FL gesetzt ist, da in diesem Fall dieselben Union-Bytes eine ocfs2_extent_list (rf_list) halten, nicht die Refcount-Datensatzliste (rf_records) – dieses Layout wird bereits separat von ocfs2_validate_extent_block() validiert, wenn der referenzierte Extent-Block gelesen wird. Dies spiegelt den vorhandenen "!(rb->rf_flags & OCFS2_REFCOUNT_TREE_FL)"-Guard wider, der an anderer Stelle in dieser Datei (z. B. ocfs2_get_refcount_rec()) verwendet wird, um zu entscheiden, ob rf_records oder rf_list das aktive Mitglied der Union ist.
Mit diesen Maßnahmen wird ein gefälschter rl_used/rl_count zur Blockvalidierungszeit erkannt (ocfs2_error()), konsistent mit jeder anderen Korruptionsprüfung in dieser Funktion, anstatt einen Out-of-Bounds-Lesezugriff in ocfs2_find_refcount_rec_in_rl() und einen nachfolgenden Out-of-Bounds-memmove() in ocfs2_insert_refcount_rec() zu verursachen.
Verifiziert gegen ein gefälschtes Image auf einem v6.19 KASAN (KASAN_GENERIC)-Build: Das Wiederholen desselben Reflinks (FICLONE) löste vor diesem Patch zuverlässig einen KASAN-Bericht in __ocfs2_increase_refcount()/ocfs2_insert_refcount_rec() aus und verursacht nach der Einführung von ocfs2_validate_refcount_block(), das den gefälschten rl_used/rl_count ablehnt, keinen Bericht mehr.
Be aware that VulDB is the high quality source for vulnerability data.