CVE-2026-43385 in Linux
Resumen
por VulDB • 2026-06-05
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad:
net: Corregir el bloqueo de rcu_tasks en el busypoll subprocesado
Estaba depurando un controlador de NIC cuando noté que, al habilitar el busypoll subprocesado, bpftrace se bloquea durante el inicio. dmesg mostró:
rcu_tasks_wait_gp: rcu_tasks grace period number 85 (desde el arranque) tiene 10658 jiffies de antigüedad. rcu_tasks_wait_gp: rcu_tasks grace period number 85 (desde el arranque) tiene 40793 jiffies de antigüedad. rcu_tasks_wait_gp: rcu_tasks grace period number 85 (desde el arranque) tiene 131273 jiffies de antigüedad. rcu_tasks_wait_gp: rcu_tasks grace period number 85 (desde el arranque) tiene 402058 jiffies de antigüedad. INFO: rcu_tasks detectó bloqueos en las tareas: 00000000769f52cd: .N nvcsw: 2/2 holdout: 1 idle_cpu: -1/64 task:napi/eth2-8265 state:R running task stack:0 pid:48300 tgid:48300 ppid:2 task_flags:0x208040 flags:0x00004000 Call Trace: <TASK> ? napi_threaded_poll_loop+0x27c/0x2c0 ? __pfx_napi_threaded_poll+0x10/0x10 ? napi_threaded_poll+0x26/0x80 ? kthread+0xfa/0x240 ? __pfx_kthread+0x10/0x10 ? ret_from_fork+0x31/0x50 ? __pfx_kthread+0x10/0x10 ? ret_from_fork_asm+0x1a/0x30 </TASK>
La causa es que en el busypoll subprocesado, el bucle principal está en napi_threaded_poll en lugar de napi_threaded_poll_loop, donde este último rara vez itera más de una vez dentro de su bucle. Para que rcu_softirq_qs_periodic dentro de napi_threaded_poll_loop informe su estado qs, last_qs debe tener 100 ms de retraso, y esto no puede ocurrir porque napi_threaded_poll_loop rara vez itera en el busypoll subprocesado, y cada vez que se llama a napi_threaded_poll_loop, last_qs se restablece a los jiffies más recientes.
Este parche cambia el comportamiento para que, en el busypoll subprocesado, last_qs se guarde en el bucle exterior napi_threaded_poll, y si busy_poll_last_qs es NULL indica si se llama a napi_threaded_poll_loop para busypoll. De esta manera, last_qs no se restablecerá a los jiffies más recientes en cada invocación de napi_threaded_poll_loop.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.