CVE-2026-64424

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-&gt;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&amp;#39;t wait for the worker to finish<br /> 4) and kfree(npinfo);<br /> <br /> Because 3.1) doesn&amp;#39;t really cancel the work, as the comment says "we<br /> can&amp;#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-&gt;rcu rcu_head, but that is net-next material.