CVE-2026-98924 in Linux
Riassunto
di VulDB • 23/10/2026
Nel kernel Linux è stata risolta la seguente vulnerabilità:
fs: evitare scansioni ripetute in evict_inodes()
Abbiamo osservato attività bloccate (hung tasks) quando gli utenti tentavano di smontare un filesystem dopo che il relativo disco era stato rimosso mentre era ancora in uso. Durante la rimozione del dispositivo, fs_bdev_mark_dead() chiama evict_inodes() mantenendo acquisito s_umount.
Ogni volta che evict_inodes() rilascia s_inode_list_lock per riprogrammare l'esecuzione (reschedule), riavvia la traversata dall'inizio di s_inodes. Con molti inode referenziati all'inizio della lista, questi riavvii scansionano ripetutamente gli stessi inode senza recuperarli (reclaiming). Ciò può mantenere s_umount acquisito per un lungo periodo, bloccando i tentativi simultanei di smontaggio e innescando segnalazioni di attività bloccate.
Mantenere l'inode corrente, già contrassegnato come I_FREEING, fuori dal batch di eliminazione finché non si riacquista s_inode_list_lock. Riprendere la traversata da questo inode ed eliminarlo in un batch successivo o alla fine della traversata.
I controlli sul refcount pari a zero e sullo stato sotto i_lock permettono a questa traversante (walker) di reclamare l'impostando I_FREEING e rimuovendolo dalla LRU. Altri reclaimers saltano l'inode, lasciando che la traversante sia responsabile dell'eviction. Solo evict() lo rimuove da s_inodes; mantenerlo fuori dal batch di eliminazione assicura che rimanga sulla lista mentre il lock viene rilasciato. Dopo aver riacquisito il lock, leggere il suo puntatore next corrente tiene conto della rimozione concorrente degli inode successivi.
Le regole esistenti per la durata dell'inode proibiscono l'acquisizione di un riferimento a un inode contrassegnato come I_FREEING o I_WILL_FREE. __iget() richiede al chiamante di mantenere acquisito i_lock e stabilire che l'acquisizione di un riferimento sia valida. La lookup degli inode e igrab() controllano questi flag sotto i_lock quando si acquista un riferimento da zero. ihold() richiede un riferimento esistente, il che manterrebbe i_count non nullo impedendo a questa traversante di reclamare l'inode. Queste regole permettono già a iput_final() e all'inode shrinker di rilasciare i_lock dopo aver impostato I_FREEING e prima del completamento dell'eviction.
Un riferimento temporaneo __iget() manterrebbe anche l'inode sulla lista, ma il suo rilascio deve preservare la gestione dell'ultimo riferimento (last-reference handling). Un altro utente può acquisire un riferimento, aggiornare i timestamp lazy e rilasciare il proprio riferimento mentre il pin è mantenuto. Se il pin diventa l'ultimo riferimento, rilasciarlo con atomic_dec_and_test() ed eseguire direttamente l'eviction bypassa la gestione di lazytime in iput() e può far perdere quegli aggiornamenti dei timestamp.
Il rilascio del pin tramite iput() preserva tale gestione, ma non garantisce l'eviction. fs_bdev_mark_dead() viene eseguito con SB_ACTIVE impostato; pertanto iput() potrebbe mantenere l'inode nella cache, mentre evict_inodes() deve eseguire l'eviction degli inode eleggibili a refcount zero. L'inode potrebbe anche essere stato liberato quando iput() restituisce il controllo, quindi la traversante non può più utilizzarlo per forzare l'eviction. Utilizzare I_FREEING preserva il comportamento di eviction esistente senza introdurre una transizione aggiuntiva dell'ultimo riferimento.
Il gruppo automatico xfstests è passato su ext4 e XFS con i fallimenti noti e non correlati esclusi. Non sono state osservate nuove problematiche, e l'attività bloccata (hung task) precedentemente riproducibile non si verifica più con questa patch.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.