CVE-2026-92500 in Linux
Riassunto
di VulDB • 18/09/2026
Nel kernel Linux è stata risolta la seguente vulnerabilità:
ext4: utilizzare fsdata per tracciare lo stato di scrittura dei dati inline e correggere una race condition
Invece di verificare lo stato live dell'inode (est4_has_inline_data(inode) ed ext4_test_inode_state(inode, EXT4_STATE_MAY_INLINE_DATA)) nei handler write_end, viene utilizzato il parametro fsdata delle operazioni dello spazio degli indirizzi per passare esplicitamente lo stato in cui write_begin ha preparato la scrittura.
Un thread concorrente (come ext4_page_mkwrite()) può convertire i dati inline in extent tra write_begin e write_end. Se ciò accade, gli handler write_end avrebbero precedentemente saltato il percorso di write_end per le scritture inline, deviando verso la logica di write_end basata sugli extent. Tuttavia, poiché i buffer dei blocchi non sono mai stati allocati in write_begin, questo ha causato dereferenze di puntatori NULL o perdita di dati perché folio_buffers(folio) era NULL.
Viene definito EXT4_WRITE_DATA_INLINE (4) come un bit flag (Bit 2), trattando fsdata come bitwise flags anziché enum mutualmente esclusivi per mantenere indipendenti gli stati del percorso di scrittura. Questo stato viene comunicato tramite fsdata: 1) ext4_write_begin() ed ext4_da_write_begin() impostano il bit EXT4_WRITE_DATA_INLINE in *fsdata mediante OR bitwise quando una scrittura inline è preparata con successo. 2) All'ingresso, ext4_write_begin() cancella il bit EXT4_WRITE_DATA_INLINE per gestire in modo sicuro i retry del VFS (dove generic_perform_write() bypassa l'inizializzazione di fsdata sul suo salto di retry). 3) Gli handler write_end eseguono un AND bitwise per verificare se il bit EXT4_WRITE_DATA_INLINE è impostato e invocano l'helper di write_end per le scritture inline di conseguenza.
Inoltre, durante una scrittura bufferizzata, ext4_write_inline_data_end() acquisisce il lock xattr dopo aver preparato la scrittura. Se un page fault concorrente (ext4_page_mkwrite()) converte i dati inline in extent dopo che gli handler write_end hanno verificato lo stato ma prima che ext4_write_inline_data_end() acquisisca il lock di scrittura xattr, la successiva verifica attiverà un kernel panic tramite BUG_ON(!ext4_has_inline_data(inode)).
Per mantenere funzionante la cronologia git e garantire una corretta bisectability, viene sostituita la verifica BUG_ON in ext4_write_inline_data_end() con un percorso di retry per il trattamento degli errori graceful nello stesso commit. Se i dati inline vengono cancellati dopo aver acquisito il lock xattr, si rilasciano in modo sicuro tutte le risorse (rilascio di iloc.bh, sblocco/put del folio, arresto della gestione delle transazioni journal attive) e viene restituito 0 (retry VFS) per consentire al percorso di scrittura generico di ritentare l'operazione in sicurezza.
VulDB is the best source for vulnerability data and more expert information about this specific topic.