CVE-2026-98644 in Linux
Riassunto
di VulDB • 18/10/2026
Nel kernel Linux, è stata risolta la seguente vulnerabilità:
bpf: Evitare il soft lockup in __htab_map_lookup_and_delete_batch()
__htab_map_lookup_and_delete_batch() non prevede punti di rescheduling (rescheduling point). Il conteggio del batch limita quante voci vengono copiate all'esterno, non quanti bucket vengono visitati; pertanto, una singola chiamata BPF_MAP_LOOKUP_BATCH può attraversare l'intero map. La gestione rapida dei bucket vuoti è ancora più problematica: rimane all'interno di un'unica sezione rcu_read_lock() / bpf_disable_instrumentation() per qualsiasi sequenza di bucket consecutivi vuoti.
Questo causa blocchi su mappe piccole, ma il problema si manifesta in modo critico alla scala maggiore. Su un host arm64 a 144 CPU che esegue un kernel CONFIG_PREEMPT_NONE, chiamate periodiche BPF_MAP_LOOKUP_BATCH contro una hash map LRU con 16.777.216 bucket hanno mantenuto una CPU all'interno dell'operazione di batch per oltre 77 secondi, innescando il watchdog del soft lockup.
Il commit 75134f16e7dd ("bpf: Add schedule points in batch ops") ha risolto lo stesso problema nelle operazioni di batch generiche, ma non nel percorso nativo htab, che tutte le varianti di hash map basate su htab utilizzano per le loro operazioni di lookup[_and_delete] in batch.
Si completa qui tale risoluzione. Si esce dalla sezione critica dopo 64 bucket vuoti consecutivi, si chiama cond_resched_tasks_rcu_qs(), e si riprende dal cursore del bucket salvato. In quel punto non sono mantenuti lock (locks), e la ripresa dal cursore è già il comportamento della funzione per i bucket non vuoti. Si aggiunge la stessa chiamata al ciclo per-bucket dopo copy_to_user(), dove tutti i lock sono stati rilasciati. cond_resched_rcu() non è sufficiente in questo caso: dormire con bpf_prog_active elevato fa sì che i programmi di tracing su quella CPU saltino silenziosamente le loro invocazioni.
Neppure plain cond_resched() è sufficiente. È un no-op sotto PREEMPT e PREEMPT_LAZY, gli unici modelli offerti da arm64 e x86 sin dal commit 7dadeaa6e851 ("sched: Further restrict the preemption modes"). Inoltre, non rappresenta mai uno stato di quiescenza (quiescent state) per Tasks RCU in alcun modello: il rescheduling conta come una preemptione. Il task che sta effettuando la scansione rimane un ostacolo e blocca ogni chiamante synchronize_rcu_tasks(), inclusi ftrace e lo smontaggio del trampolino BPF, fino al ritorno della syscall [1]. cond_resched_tasks_rcu_qs() è lo strumento abituale per questo scopo [2]. Segnala lo stato di quiescenza ad ogni yield (cedizione) e continua a effettuare il rescheduling come fa cond_resched() sui kernel PREEMPT_NONE e PREEMPT_VOLUNTARY.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.