CVE-2026-64424
Gravedad:
Pendiente de análisis
Tipo:
No Disponible / Otro tipo
Fecha de publicación:
25/07/2026
Última modificación:
25/07/2026
Descripción
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br />
<br />
netpoll: fix a use-after-free on shutdown path<br />
<br />
There is a use-after-free error on netpoll, which is clearly detected by<br />
KASAN.<br />
<br />
BUG: KASAN: slab-use-after-free in _raw_spin_lock_irqsave+0x3b/0x80<br />
Read of size 1 at addr ... by task kworker/9:1<br />
Workqueue: events queue_process<br />
Call Trace:<br />
skb_dequeue+0x1e/0xb0<br />
queue_process+0x2c/0x600<br />
process_scheduled_works+0x4b6/0x850<br />
worker_thread+0x414/0x5a0<br />
Allocated by task 242:<br />
__netpoll_setup+0x201/0x4a0<br />
netpoll_setup+0x249/0x550<br />
enabled_store+0x32f/0x380<br />
Freed by task 0:<br />
kfree+0x1b7/0x540<br />
rcu_core+0x3f8/0x7a0<br />
<br />
The problem happens when there is a pending TX worker running in<br />
parallel with the cleanup path.<br />
<br />
This is what happens on netpoll shutdown path:<br />
<br />
1) __netpoll_cleanup() is called<br />
2) set dev->npinfo to NULL<br />
3) call_rcu() with rcu_cleanup_netpoll_info()<br />
3.1) rcu_cleanup_netpoll_info() tries to cancel all workers with<br />
cancel_delayed_work(), but doesn&#39;t wait for the worker to finish<br />
4) and kfree(npinfo);<br />
<br />
Because 3.1) doesn&#39;t really cancel the work, as the comment says "we<br />
can&#39;t call cancel_delayed_work_sync here, as we are in softirq", the TX<br />
worker can run after 4).<br />
<br />
Tl;DR: queue_process() is not an RCU reader, it reaches npinfo through<br />
the work item via container_of().<br />
<br />
Use disable_delayed_work_sync() to ensure the worker is completely<br />
stopped and prevent any future re-arming attempts. Once npinfo is set<br />
to NULL, senders will bail out and not queue new work. The disable flag<br />
ensures any in-flight re-arming attempts also fail silently.<br />
<br />
In the future, we can do the cleanup inline here without needing the<br />
npinfo->rcu rcu_head, but that is net-next material.



