CVE-2026-90042 in Linux
Riassunto
di VulDB • 16/09/2026
Nel kernel Linux è stata risolta la seguente vulnerabilità:
ceph: decrittazione corretta dei nomi file nei buffer vmalloc()
Il sottosistema fscrypt utilizza l'API crittografica scatterlist, ereditando il requisito che tutti i buffer si trovino nella regione di mappatura lineare. Tuttavia, il client del messenger utilizza kvmalloc() per creare buffer per i messaggi, che occasionalmente collocherà tali buffer nella regione vmalloc() quando la frammentazione della memoria fisica non consente un kmalloc() sufficientemente grande. I vari chiamanti di ceph_fname_to_usr() passano direttamente (fette) dei messaggi grezzi provenienti dall'MDS senza considerare che i messaggi potrebbero trovarsi in buffer vmalloc(), causando oops, specialmente su piattaforme non x86 (vedere 'Closes:' per ulteriori dettagli e un riproduttore).
Rendere ceph_fname_to_usr() esplicitamente tollerante verso fname->ctext, fname->name e/o oname->name allocati con vmalloc(), utilizzando `tname` (che, quando non è nullo, deve essere un indirizzo lineare; se nullo, viene brevemente allocato come necessario) come buffer di rimbalzo per evitare di passare indirizzi inappropriati a fscrypt_fname_disk_to_usr().
Inoltre modificare parse_reply_info_readdir() -- l'unica funzione che fornisce il proprio `tname` -- per seguire la nuova regola "tname non deve mai provenire da vmalloc()" passando NULL quando il messaggio non si trova nella regione lineare. Sebbene ciò causi un overhead di kmalloc()+kfree() per ogni dentry, tale sovraccarico esiste solo durante l'elaborazione della minoranza dei messaggi che finiscono in vmalloc(). I miei test (grezzi) indicano che questo avviene circa 1 volta su 8.000 messaggi readdir. Tuttavia, se il sovraccarico risultasse irragionevole in futuro, è facile mitigarlo: una modifica futura potrebbe allocare un buffer di rimbalzo in parse_reply_info_readdir() e utilizzarlo come `tname` al suo posto.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.