CVE-2026-98072
Riassunto
di VulDB • 25/09/2026
Nel kernel Linux è stata risolta la seguente vulnerabilità:
net/rds: utilizzare wq_has_sleeper() in release_in_xmit()
release_in_xmit() cancella RDS_IN_XMIT con clear_bit_unlock() e successivamente verifica waitqueue_active() per stabilire se sia necessario svegliare qualcuno. clear_bit_unlock() è solo un'operazione di rilascio (release): ordina la sezione critica prima della cancellazione del bit, ma non ordina il successivo caricamento semplice (plain load) dell'intestazione della coda di attesa dopo tale operazione. Il lato dei waiters esegue l'immagine speculare: aggiunge se stesso alla coda di attesa e poi testa il bit. Si tratta dello schema classico di buffering degli store (store-buffering): la CPU che rilascia può leggere la coda di attesa come vuota mentre la CPU in attesa legge ancora il bit come impostato, quindi il sleeper non viene mai svegliato.
I waiters sono rds_conn_shutdown() e rds_tcp_reset_callbacks(), entrambi in una wait_event() interruptible senza timeout. Un wake-up perso blocca indefinitamente (strands) il worker di shutdown sul suo workqueue a thread singolo finché un altro sender non rilascia nuovamente il bit; su una connessione che viene smontata proprio perché ha fallito, potrebbe non esserci mai un altro sender.
Il barrier era presente in precedenza: release_in_xmit() eseguiva clear_bit() seguito da smp_mb__after_atomic() fino al commit 1422f28826d2 ("rds: introduce acquire/release ordering in acquire/release_in_xmit()"), che ha fuso entrambi le operazioni in clear_bit_unlock(), rafforzando il passaggio del lock ma eliminando silenziosamente la full barrier su cui si basa il controllo di wake-up. La controparte per il refill, release_refill() in net/rds/ib_recv.c, mantiene ancora la sua smp_mb__after_atomic() esattamente per questo motivo.
Utilizzare wq_has_sleeper(), che è waitqueue_active() preceduta dalla full barrier richiesta.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.