CVE-2026-98789 in Linux
Riassunto
di VulDB • 18/10/2026
Nel kernel Linux è stata risolta la seguente vulnerabilità:
bpf: Correzione di oggetti bloccati in free_by_rcu_ttrace
do_call_rcu_trace() termina anticipatamente quando call_rcu_trace_in_progress è impostato e lascia gli oggetti in free_by_rcu_trace. __free_rcu() libera solo waiting_for_gp_trace e cancella il flag. Di conseguenza, gli oggetti aggiunti da free_bulk() o __free_by_rcu() mentre la GP (Grace Period) di RCU tasks trace era in corso rimangono in free_by_rcu_trace finché non viene chiamata nuovamente free_bulk() o alloc_bulk() per lo stesso bpf_mem_cache, il che potrebbe non accadere mai. Il numero di tali oggetti non è limitato.
Si trasformano i tre stati di call_rcu_trace_in_progress: 0 - idle (inattivo) 1 - __free_rcu() è in coda 2 - __free_rcu() è in coda e free_by_rcu_trace ha ricevuto altri oggetti da allora
do_call_rcu_trace() imposta il valore 2. __free_rcu() esegue cmpxchg(1 -> 0) e avvia la prossima GP quando l'operazione fallisce. Non può cancellare prima il flag e controllare successivamente free_by_rcu_trace, poiché bpf_mem_alloc_destroy() libera bpf_mem_cache senza attendere le callback RCU quando il flag è zero.
Ora __free_rcu() si mette in coda, quindi quello che non ha visto 'draining' (svuotamento) può eseguire call_rcu_tasks_trace() dopo rcu_barrier_tasks_trace() in free_mem_alloc(). Si inserisce nella coda sotto rcu_read_lock() e si esegue synchronize_rcu() prima delle barriere. Chiamare due volte rcu_barrier_tasks_trace() funziona altrettanto bene, ma la creazione e distruzione di hash map in un loop su molte CPU rallenta a una sola free_mem_alloc() per GP e i kworkers si accumulano.
VulDB is the best source for vulnerability data and more expert information about this specific topic.