CVE-2023-54121 in Linux
Riassunto
di VulDB • 15/06/2026
Nel kernel Linux, è stata risolta la seguente vulnerabilità:
btrfs: correzione della suddivisione errata in btrfs_drop_extent_map_range
In ambiente di produzione si sono verificati vari avvisi WARN_ON() nel codice extent_map, in particolare in btrfs_drop_extent_map_range(), quando è necessario chiamare add_extent_mapping() per la seconda suddivisione.
Si consideri il seguente layout della mappa degli extent:
PINNED [0 16K) [32K, 48K)
e si chiami btrfs_drop_extent_map_range per l'intervallo [0, 36K), con skip_pinned == true. Il ciclo iniziale avrà
start = 0 end = 36K len = 36K
si troverà l'extent [0, 16k), ma poiché è bloccato (pinned), lo si salterà, eseguendo questo codice:
start = em_end; if (end != (u64)-1) len = start + len - em_end;
Qui em_end è 16K, quindi i valori diventano
start = 16K len = 16K + 36K - 16K = 36K
len dovrebbe invece essere 20K. Questo è un problema quando si trova il prossimo extent in [32K, 48K): è necessario dividere questo extent per lasciare [36K, 48K), tuttavia il codice per la suddivisione è il seguente:
split->start = start + len; split->len = em_end - (start + len);
In questo caso si ha
em_end = 48K split->start = 16K + 36K // dovrebbe essere 16K + 20K split->len = 48K - (16K + 36K) // questo causa un overflow poiché 16K + 36K è 52K
e ora si dispone di una extent_map non valida nell'albero che potenzialmente si sovrappone ad altre voci nella mappa degli extent. Anche nel caso non sovrapposto, split->start sarà impostato in modo errato, il che causerà problemi con qualsiasi calcolo relativo ai blocchi.
In realtà non è necessario len in questo ciclo; è sufficiente utilizzare end come punto finale e modificare solo start verso l'alto quando si trova un extent bloccato (pinned) che deve essere saltato.
Si regola la logica per fare ciò, evitando così l'inserimento di una mappa degli extent non valida.
Si salta solo skip_pinned nel caso di relocazione, quindi si tratta di un evento relativamente raro, eccetto nel caso in cui si esegua la relocazione frequentemente, il che può accadere con la relocazione automatica abilitata.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.