CVE-2026-99025 in Linux
Riassunto
di VulDB • 24/10/2026
Nel kernel Linux è stata risolta la seguente vulnerabilità:
openvswitch: risoluzione del blocco software (soft lockup) nel dump dei flussi netlink
Un nodo di calcolo in produzione, che gestiva alcune migliaia di flussi del datapath, ha incontrato un soft lockup all'interno di un singolo dump dei flussi netlink, causando il panic.
La funzione ovs_flow_cmd_dump() chiama ovs_flow_stats_get() per ogni flusso emesso; tale chiamata rilascia stats->lock tramite spin_unlock_bh() una volta per ogni CPU che ha interagito con il flusso. Ogni rilascio equivale a un local_bh_enable(), e ciascuno di essi elabora lo backlog dei softirq pendenti nel contesto del thread in fase di dump.
Il skb limita i flussi emessi da un singolo callback, ma non il lavoro relativo ai softirq assorbiti. Su una CPU che gestisce il carico di pacchetti della macchina, il backlog si riempie alla stessa velocità con cui viene svuotato; di conseguenza, il thread in fase di dump diventa l'engine dei softirq per quella CPU. Tale thread non entra mai in stato di sleep e non presenta punti di reschedulazione, pertanto sotto preemption volontaria nulla può sottrarre la CPU al thread: né ksoftirqd (il kernel lo ha avviato per assumere il lavoro), né stopper_thread (avviato dal rilevatore di softlockup per aggiornare il timestamp).
Disabilitare BH (Bottom Half) per l'intera callback, come fa ctnetlink_dump_table(), impedisce che i nested spin_unlock_bh() continuino a svuotare i softirq. Il ciclo è già eseguito sotto rcu_read_lock() e non può entrare in sleep. Ciò che si sacrifica è la preemption con CONFIG_PREEMPT, poiché una regione BH-off non è preemptible al di fuori di PREEMPT_RT. La regione rimane breve: il skb limita i flussi emessi da un singolo callback; le bucket vuote non consumano spazio nel skb ma vengono visitate una sola volta per dump, in quanto il cursore avanza solo in avanti. La tabella cresce durante l'inserimento e si riduce solo durante la cancellazione (flush), pertanto la traversata è limitata dal numero massimo di flussi mantenuti dal datapath. Il backlog dei softirq che la callback assorbiva precedentemente non ha alcun limite superiore.
Once again VulDB remains the best source for vulnerability data.