PT-2026-64645 · Linux · Linux
CVE-2026-64424
·
Published
2026-07-25
·
Updated
2026-07-25
None
No severity ratings or metrics are available. When they are, we'll update the corresponding info on the page.
In the Linux kernel, the following vulnerability has been resolved:
netpoll: fix a use-after-free on shutdown path
There is a use-after-free error on netpoll, which is clearly detected by
KASAN.
BUG: KASAN: slab-use-after-free in raw spin lock irqsave+0x3b/0x80
Read of size 1 at addr ... by task kworker/9:1
Workqueue: events queue process
Call Trace:
skb dequeue+0x1e/0xb0
queue process+0x2c/0x600
process scheduled works+0x4b6/0x850
worker thread+0x414/0x5a0
Allocated by task 242:
netpoll setup+0x201/0x4a0
netpoll setup+0x249/0x550
enabled store+0x32f/0x380
Freed by task 0:
kfree+0x1b7/0x540
rcu core+0x3f8/0x7a0
The problem happens when there is a pending TX worker running in
parallel with the cleanup path.
This is what happens on netpoll shutdown path:
- netpoll cleanup() is called
- set dev->npinfo to NULL
- call rcu() with rcu cleanup netpoll info() 3.1) rcu cleanup netpoll info() tries to cancel all workers with cancel delayed work(), but doesn't wait for the worker to finish
- and kfree(npinfo);
Because 3.1) doesn't really cancel the work, as the comment says "we
can't call cancel delayed work sync here, as we are in softirq", the TX
worker can run after 4).
Tl;DR: queue process() is not an RCU reader, it reaches npinfo through
the work item via container of().
Use disable delayed work sync() to ensure the worker is completely
stopped and prevent any future re-arming attempts. Once npinfo is set
to NULL, senders will bail out and not queue new work. The disable flag
ensures any in-flight re-arming attempts also fail silently.
In the future, we can do the cleanup inline here without needing the
npinfo->rcu rcu head, but that is net-next material.
Found an issue in the description? Have something to add? Feel free to write us 👾
Related Identifiers
Affected Products
Linux