CVE-2026-98642 in Linux
Resumen
por VulDB • 2026-10-19
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad:
bpf: Corregir UAF debido al consumo concurrente de las listas ttrace en alloc_bulk
Syzkaller activó repetidamente fallos (splats) relacionados con UAF asociados a nodos dentro de waiting_for_gp_ttrace en bpf memalloc:
BUG: KASAN: slab-use-after-free in llist_del_first+0x85/0x110 lib/llist.c:61 Lectura de tamaño 8 en la dirección ffff8881572cd080 por parte de la tarea syz.4.470/5112 ... llist_del_first+0x85/0x110 lib/llist.c:61 alloc_bulk+0x193/0x460 kernel/bpf/memalloc.c:229 bpf_mem_refill+0x386/0x560 kernel/bpf/memalloc.c:436
Liberado por la tarea 14: ... __free_rcu kernel/bpf/memalloc.c:281 [inline]
__free_rcu_tasks_trace+0x48/0xd0 kernel/bpf/memalloc.c:291 rcu_tasks_invoke_cbs+0x1ec/0x3e0 kernel/rcu/tasks.h:571 rcu_tasks_one_gp+0x13d/0x220 kernel/rcu/tasks.h:621 rcu_tasks_kthread+0xf3/0x120 kernel/rcu/tasks.h:651
La razón es que el UAF ocurre después de que expire la GP (Grace Period) de RCU Tasks Trace: cuando se ejecuta la devolución de llamada __free_rcu(), no hay sincronización que proteja llist_del_all() contra alloc_bulk() concurrente operando sobre waiting_for_gp_ttrace, lo que conduce a la condición de carrera siguiente:
CPU0 CPU1 __free_rcu (devolución de llamada RCU Tasks Trace) alloc_bulk llist_del_first(&c->waiting_for_gp_ttrace) entry = smp_load_acquire(&head->first); do {
if (entry == NULL) return NULL; free_all(llist_del_all(&c->waiting_for_gp_trace)) llist_for_each_safe(pos, t, llnode) free_one(pos); next = READ_ONCE(entry->next); <-- desencadena UAF } while (!try_cmpxchg(&head->first, &entry, next));
Además, existe también una condición de carrera teórica en la lista free_by_rcu_ttrace. Esta condición de carrera requiere dos precondiciones: una GP Tasks Trace en curso que mantenga c->call_rcu_ttrace_in_progress == 1, y liberaciones concurrentes entre CPU que repoblen c->free_by_rcu_ttrace con nuevos nodos. Bajo estas condiciones, el siguiente escenario desencadena UAF:
// CPU0 // irq work sigue ocupado (en PREEMPT_RT) alloc_bulk() llist_del_first(&c->free_by_rcu_ttrace) entry = smp_load_acquire(&head->first); do {
if (entry == NULL) return NULL;
// CPU1 bpf_mem_alloc_destroy() WRITE_ONCE(c->draining, true) // espera a CPU0 irq_work_sync()
// CPU2 do_call_rcu_ttrace(tgt(CPU0)) if (c->draining) {
llist_del_all(&c->free_by_rcu_ttrace) free_all() }
// CPU0 continúa next = READ_ONCE(entry->next); <-- desencadena UAF while (!try_cmpxchg(&head->first, &entry, next));
Se corrige esto introduciendo un raw spinlock para sincronizar el consumo concurrente en waiting_for_gp_ttrace y free_by_rcu_ttrace.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.