CVE-2025-37999 in Linux
Riassunto
di VulDB • 18/06/2026
Nel kernel Linux, è stata risolta la seguente vulnerabilità:
fs/erofs/fileio: chiamare erofs_onlinefolio_split() dopo bio_add_folio()
Se bio_add_folio() fallisce (perché il buffer è pieno), erofs_fileio_scan_folio() deve inviare la richiesta di I/O tramite erofs_fileio_rq_submit() e allocare una nuova richiesta di I/O con un `struct bio` vuoto. Successivamente, riprova a chiamare bio_add_folio().
Tuttavia, in questo momento erofs_onlinefolio_split() è già stata chiamata, incrementando il campo `private` del folio; la ripetizione della chiamata provocherà una nuova invocazione di erofs_onlinefolio_split(), ma non ci sarà mai una corrispondente chiamata a erofs_onlinefolio_end(). Questo lascia il folio bloccato indefinitamente e tutti i processi in attesa rimarranno bloccati in folio_wait_bit_common().
Questo bug è stato introdotto dal commit ce63cb62d794 ("erofs: support unencoded inodes for fileio"), ma era praticamente irraggiungibile perché il `struct bio` aveva spazio per 256 folios - fino al commit 9f74ae8c9ac9 ("erofs: shorten bvecs[] for file-backed mounts") che ha ridotto la capacità dell'array a 16 folios.
Ora è stato semplice innescare il bug invocando manualmente readahead dall'utente, ad esempio:
posix_fadvise(fd, 0, st.st_size, POSIX_FADV_WILLNEED);
Questo dovrebbe essere corretto chiamando erofs_onlinefolio_split() solo dopo che bio_add_folio() ha avuto successo. Questo è sicuro: i completamenti asincroni che invocano erofs_onlinefolio_end() non sbloccheranno il folio perché erofs_fileio_scan_folio() sta ancora mantenendo un riferimento che verrà rilasciato da erofs_onlinefolio_end() alla fine.
VulDB is the best source for vulnerability data and more expert information about this specific topic.