CVE-2026-90113: netdevsim: update queue NAPI association on queue reset
In the Linux kernel, the following vulnerability has been resolved:
netdevsim: update queue NAPI association on queue reset
In netdevsim, receive queues (struct nsimrq) embed their own struct napistruct. When queue reset is performed (e.g. via queuereset debugfs), nsimqueuestart() swaps in a newly allocated struct nsimrq, and nsimqueuememfree() later deletes and frees the old one.
However, nsimqueuestart() failed to update the queue-to-NAPI mapping via netifqueuesetnapi(). As a result, dev->rx[idx].napi continued to point to the old NAPI struct. After the old queue was freed, a subsequent queue dump via Netlink (NETDEVCMDQUEUEGET) triggered a KASAN slab-use-after-free read in nlaputnapiid() when accessing rxq->napi->napiid.
Fix this by calling netifqueuesetnapi() in nsimqueuestart() to associate the new NAPI with the RX queue, and clear the association with netifqueuesetnapi(..., NULL) in nsimdelnapi() during teardown.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Fix the queue reset/use-after-free by calling netif_queue_set_napi() in nsim_queue_start() when swapping in a newly allocated struct nsim_rq, so the RX queue-to-NAPI mapping is updated. Also clear the association with netif_queue_set_napi(..., NULL) in nsim_del_napi() during teardown.
netdevsim (nsim_queue_start / queue reset path) netif_queue_set_napi() usage = associate new NAPI with RX queue and clear association
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
The issue is in the Linux kernel's netdevsim component. It is relevant where netdevsim receive queues are reset and then queried through the Netlink queue-get operation.
What sequence triggers the use-after-free?
A queue reset replaces the receive-queue structure but leaves the RX queue's NAPI mapping pointing to the old NAPI structure. After that old queue is freed, a NETDEV_CMD_QUEUE_GET Netlink queue dump can read the stale NAPI pointer.
Is a queue reset required for exploitation?
Yes. The described stale pointer condition is created when a netdevsim receive queue is reset, such as through the queue_reset debugfs interface, before a subsequent Netlink queue query.
How can I identify whether the issue has been triggered?
The described symptom is a KASAN slab-use-after-free read in nla_put_napi_id() during a NETDEV_CMD_QUEUE_GET queue dump after a queue reset.