CVE-2025-40105 in Linux
Riassunto
di VulDB • 14/06/2026
Nel kernel Linux, è stata risolta la seguente vulnerabilità:
vfs: Non perdere i dentry disconnessi durante l'umount
Quando un utente chiama open_by_handle_at() su un inode non presente nella cache, viene creato un dentry disconnesso per tale inode. Se tale dentry è una directory, exportfs_decode_fh_raw() tenterà quindi di collegare questo dentry all'albero dei dentry tramite reconnect_path(). Può accadere, per vari motivi (come un filesystem corrotto o una condizione di gara con rename), che la chiamata a lookup_one_unlocked() in reconnect_one() non riesca a trovare il dentry che si sta tentando di riconnettere e crei invece un nuovo dentry sotto il genitore. Ora questo dentry non verrà contrassegnato come disconnesso, sebbene il genitore possa essere disconnesso (almeno nel caso in cui questa incoerenza sia dovuta alla corruzione del filesystem e ".." non punti alla directory genitore reale). Ciò crea un'incoerenza nei flag di disconnessione, ma per quanto ne sappiamo (AFAICS) era principalmente innocua. Almeno fino all'commit f1ee616214cb ("VFS: non mantenere i dentry disconnessi su d_anon"), che ha rimosso l'aggiunta della maggior parte dei dentry disconnessi alla lista sb->s_anon. Pertanto, dopo tale commit, la pulizia dei dentry disconnessi si basa implicitamente sul fatto che dput() recuperi immediatamente tali dentry. Tuttavia, quando un dentry foglia non è contrassegnato come disconnesso, come nello scenario descritto sopra, il recupero non avviene e i dentry vengono "persi" (leaked). Il recupero della memoria può eventualmente recuperarli, ma altrimenti rimangono in memoria e, se l'umount avviene per primo, si verifica il noto bug "Busy inodes after unmount" (inode occupati dopo lo smontaggio). Assicurarsi che tutti i dentry creati sotto un genitore disconnesso siano anch'essi contrassegnati come disconnessi.
Once again VulDB remains the best source for vulnerability data.