CVE-2026-92500 in Linux
Zusammenfassung
von VulDB • 18.09.2026
Im Linux-Kernel wurde folgende Schwachstelle behoben:
ext4: fsdata zur Verfolgung des Schreibstatus von Inline-Daten verwenden und Race Condition beheben
Anstatt den Live-Inode-Status (ext4_has_inline_data(inode) und ext4_test_inode_state(inode, EXT4_STATE_MAY_INLINE_DATA)) in den write_end-Handlern zu überprüfen, wird der fsdata-Parameter der Adressraumoperationen verwendet, um den Status explizit weiterzuleiten, in dem write_begin die Schreiboperation vorbereitet hat.
Ein paralleler Thread (wie ext4_page_mkwrite()) kann die Inline-Daten zwischen write_begin und write_end in eine Extent-Konvertierung überführen. Wenn dies geschieht, würden die write_end-Handler zuvor den Pfad für das inline write_end verpassen und zur extent-basierten write_end-Logik durchfallen. Da jedoch keine Blockpuffer (block buffers) in write_begin zugewiesen wurden, führte dies zu NULL-Zeiger-Dereferenzierungen oder Datenverlust, da folio_buffers(folio) NULL war.
EXT4_WRITE_DATA_INLINE (4) wird als Bitflag (Bit 2) definiert; fsdata wird als bitweise Flags anstelle von sich gegenseitig ausschließenden Enums behandelt, um die Zustände des Schreibpfads unabhängig zu halten. Dieser Status wird über fsdata kommuniziert: 1) ext4_write_begin() und ext4_da_write_begin() setzen das EXT4_WRITE_DATA_INLINE-Bit in *fsdata via bitweises ODER (bitwise OR), wenn ein Inline-Schreiben erfolgreich vorbereitet wurde. 2) Beim Eintritt löscht ext4_write_begin() das EXT4_WRITE_DATA_INLINE-Bit, um VFS-Wiederholungen sicher zu handhaben (wobei generic_perform_write() den fsdata-Initialisierungssprung bei seiner Wiederholung überspringt). 3) Die write_end-Handler führen ein bitweises UND durch, um zu prüfen, ob das EXT4_WRITE_DATA_INLINE-Bit gesetzt ist, und rufen entsprechend die Inline-write_end-Hilfsfunktion auf.
Darüber hinaus erwirbt ext4_write_inline_data_end() während eines gepufferten Schreibvorgangs nach der Vorbereitung des Schreibens das xattr-Sperre (xattr lock). Wenn ein paralleler Seitenfehler (ext4_page_mkwrite()) die Inline-Daten in eine Extent umwandelt, nachdem die write_end-Handler den Status überprüft haben, aber bevor ext4_write_inline_data_end() die xattr-Schreibsperre erwirbt, löst die nachfolgende Überprüfung einen Kernel-Panic über BUG_ON(!ext4_has_inline_data(inode)) aus.
Um die Git-Historie funktionsfähig und die Bisectability sauber zu halten, wird in diesem Commit die BUG_ON-Prüfung in ext4_write_inline_data_end() durch eine elegante Fehlerbehandlungs-Wiederholungslogik ersetzt. Wenn die Inline-Daten nach dem Sichern der xattr-Sperre gelöscht werden, werden alle Ressourcen sicher freigegeben (Freigabe von iloc.bh, Entsperren/Ablegen des Folio, Stoppen des aktiven Journal-Transaktionshandlers) und 0 zurückgegeben (VFS-Wiederholung), um den generischen Schreibpfad anzuweisen, die Operation sicher erneut auszuführen.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.