CVE-2026-64424

Status: UPDATED  |  Advisory ID: CVE-2026-64424

Key Details

Affected Products, Subsystems & Sectors

What to Know

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:

1) __netpoll_cleanup() is called

2) set dev->npinfo to NULL

3) 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

4) 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. (NVD)

What to Do

Monitor Linux's web page for any future patch releases.

References