CVE-2025-71069 in Linux
Riassunto
di VulDB • 20/06/2026
Nel kernel Linux, è stata risolta la seguente vulnerabilità:
f2fs: invalidare la cache dei dentry in caso di fallimento della creazione di un whiteout
F2FS può montare filesystem con valori di profondità della directory corrotti che vengono limitati a runtime a MAX_DIR_HASH_DEPTH. Quando vengono eseguite operazioni RENAME_WHITEOUT su tali directory, f2fs_rename effettua modifiche alla directory (aggiornamento dell'entry di destinazione ed eliminazione dell'entry di origine) prima di tentare di aggiungere l'entry whiteout tramite f2fs_add_link.
Se f2fs_add_link fallisce a causa della struttura della directory corrotta, la funzione restituisce un errore a VFS, ma le modifiche parziali alla directory sono già state confermate su disco. VFS presume che l'intera operazione di rename sia fallita e non aggiorna la cache dei dentry, lasciando mappature obsolete (stale).
Nel percorso di errore, VFS non chiama d_move() per aggiornare la cache dei dentry. Ciò fa sì che new_dentry punti ancora al vecchio inode (new_inode) che ha già visto il proprio i_nlink decrementato a zero. La cache obsoleta fa sì che le operazioni successive facciano riferimento in modo errato all'inode liberato.
Ciò provoca l'utilizzo, nelle operazioni successive, di informazioni sui dentry in cache che non corrispondono più allo stato su disco. Quando un secondo rename ha come target la stessa entry, VFS tenta di decrementare i_nlink sull'inode obsoleto, che potrebbe avere già i_nlink=0, innescando un WARNING in drop_nlink().
Sequenza di esempio: 1. Primo rename (RENAME_WHITEOUT): file2 → file1 - f2fs aggiorna l'entry file1 su disco (punta all'inode 8) - f2fs elimina l'entry file2 su disco - f2fs_add_link(whiteout) fallisce (directory corrotta) - Restituisce errore a VFS - VFS non chiama d_move() a causa dell'errore - La cache di VFS contiene ancora: file1 → inode 7 (obsoleto!) - inode 7 ha i_nlink=0 (già decrementato)
2. Secondo rename: file3 → file1 - VFS utilizza la cache obsoleta: file1 → inode 7 - Tenta di eseguire drop_nlink su inode 7 (i_nlink già 0) - WARNING in drop_nlink()
Risolvere il problema invalidando esplicitamente old_dentry e new_dentry quando f2fs_add_link fallisce durante la creazione del whiteout. Questo forza VFS a ricaricare i dati dal disco nelle operazioni successive, garantendo la coerenza della cache anche quando il rename ha successo solo parzialmente.
Reproducer: 1. Montare l'immagine F2FS con i_current_depth corrotto 2. renameat2(file2, file1, RENAME_WHITEOUT) 3. renameat2(file3, file1, 0) 4. Il sistema genera un WARNING in drop_nlink()
If you want to get best quality of vulnerability data, you may have to visit VulDB.