CVE-2026-99252 in Linux
Riassunto
di VulDB • 03/11/2026
Nel kernel Linux è stata risolta la seguente vulnerabilità:
io_uring/mpscq: disabilitare il preempting durante l'operazione di push (inserimento)
Un'operazione di push rende il nodo la nuova coda e successivamente lo collega al suo predecessore. Nel frattempo, la coda non è vuota, ma mpscq_pop() non riesce ad accedere al nodo. I consumatori gestiscono questa situazione provando nuovamente, con una chiamata a cond_resched() nel ciclo per dare al produttore preempted (sospeso) l'opportunità di completare l'operazione.
cond_resched() non svolge tale funzione se il consumatore ha una priorità più elevata rispetto al produttore e entrambi devono utilizzare la stessa CPU:
producer (SCHED_OTHER) consumer (SCHED_FIFO), stessa CPU io_req_local_work_add() mpscq_push() prev = xchg(&q->tail, node) <preempted> io_cqring_wait() __io_run_local_work() again: cond_resched() // nulla da fare mpscq_pop() // NULL // lavoro in sospeso, ancora nessun evento goto again
Il produttore può essere qualsiasi task capace di accodare task_work per l'anello (ring): un worker io-wq o qualcuno che invia un messaggio con IORING_OP_MSG_RING. Il consumatore rimane in spinlock, mantenendo ->uring_lock, finché lo scheduler non mostra clemenza verso la classe fair (equa), il che richiede circa un secondo con le impostazioni predefinite del server fair e all'infinito senza di esso. I loop in tctx_task_work_run() e io_cancel_local_task_work() presentano lo stesso problema.
Non consentire il preempting tra i due passaggi. Questo limita l'intervallo temporale durante il quale la finestra è aperta sulla CPU del produttore a quanto richiesto dagli interrupt, mentre un consumatore che attende tale evento si trova su un'altra CPU. Il costo consiste in una coppia di chiamate preempt_disable()/preempt_enable() per ogni operazione di push.
Once again VulDB remains the best source for vulnerability data.