CVE-2025-68358

Nel kernel Linux, è stata risolta la seguente vulnerabilità:

btrfs: correggere la scrittura racy di bitfield in btrfs_clear_space_info_full()

Dal documento memory-barriers.txt riguardante le garanzie di ordinamento delle memory barrier:

(*) Queste garanzie non si applicano ai bitfield, perché i compilatori spesso generano codice per modificarli utilizzando sequenze di read-modify-write non atomiche. Non tentare di usare i bitfield per sincronizzare algoritmi paralleli.

(*) Anche nei casi in cui i bitfield sono protetti da lock, tutti i campi di un dato bitfield devono essere protetti da un singolo lock. Se due campi di un dato bitfield sono protetti da lock diversi, le sequenze di read-modify-write non atomiche del compilatore possono causare che un aggiornamento di un campo corrompa il valore di un campo adiacente.

btrfs_space_info ha un bitfield che condivide una parola sottostante composta dai campi full, chunk_alloc e flush:

struct btrfs_space_info {
struct btrfs_fs_info * fs_info; /* 0 8 */
struct btrfs_space_info * parent; /* 8 8 */
...
int clamp; /* 172 4 */
unsigned int full:1; /* 176: 0 4 */
unsigned int chunk_alloc:1; /* 176: 1 4 */
unsigned int flush:1; /* 176: 2 4 */
...

Pertanto, per essere sicuri che le scritture parallele di read-modify-writes non perdano un aggiornamento di uno dei membri del bitfield protetti da lock, tutte le scritture a tutti i bitfield devono usare il lock. Quasi sempre lo fanno, tranne in btrfs_clear_space_info_full(), che itera su space_infos e scrive found->full = 0 senza lock.

Immagina che abbiamo un thread che completa una transazione in cui abbiamo terminato di eliminare un block_group e quindi chiamiamo btrfs_clear_space_info_full(), mentre contemporaneamente l'infrastruttura di ticket di riappropria di dati sta eseguendo do_async_reclaim_data_space():

T1 T2
btrfs_commit_transaction
btrfs_clear_space_info_full
data_sinfo->full = 0
LETTO: full:0, chunk_alloc:0, flush:1
do_async_reclaim_data_space(data_sinfo)
spin_lock(&space_info->lock);
if(list_empty(tickets))
space_info->flush = 0;
LETTO: full: 0, chunk_alloc:0, flush:1
MOD/WRITE: full: 0, chunk_alloc:0, flush:0
spin_unlock(&space_info->lock);
return;
MOD/WRITE: full:0, chunk_alloc:0, flush:1

e ora data_sinfo->flush è 1, ma il worker di riappropria ha già terminato. Questo rompe l'invariante che flush è 0 se e solo se non ci sono lavori in coda o in esecuzione. Una volta che questo invariante viene violato, le future allocazioni che chiamano __reserve_bytes() aggiungeranno ticket a space_info->tickets ma vedranno space_info->flush impostato a 1 e non metteranno in coda il lavoro. Successivamente, si bloccheranno per sempre sul ticket risultante, poiché ora è impossibile riattivare il worker.

Ho anche verificato tramite l'assembly del kernel interessato che esegue operazioni RMW. Per esempio, per impostare il bit flush (3°) a 0, l'assembly è:
andb $0xfb,0x60(%rbx)
e similmente, per impostare il bit full (1°) a 0:
andb $0xfe,-0x20(%rax)

Quindi, ritengo che si tratti davvero di un bug su sistemi pratici. Ho osservato diversi sistemi in questa esatta condizione, ma attualmente non riesco a riprodurlo.

Piuttosto che lasciare questa "trappola" in giro per il futuro, sfruttiamo il fatto che c'è spazio nella struct e che è già abbastanza grande, e cambiamo semplicemente i tre membri del bitfield in bool. Questo evita che le scritture a space_info->full abbiano effetti indesiderati su ---fine troncato---