CVE-2026-23340

In the Linux kernel, the following vulnerability has been resolved:

net: sched: avoid qdisc_reset_all_tx_gt() vs dequeue race for lockless qdiscs

When shrinking the number of real tx queues, netif_set_real_num_tx_queues() calls qdisc_reset_all_tx_gt() to flush qdiscs for queues which will no longer be used.

qdisc_reset_all_tx_gt() currently serializes qdisc_reset() with qdisc_lock(). However, for lockless qdiscs, the dequeue path is serialized by qdisc_run_begin/end() using qdisc->seqlock instead, so qdisc_reset() can run concurrently with __qdisc_run() and free skbs while they are still being dequeued, leading to UAF.

This can easily be reproduced on e.g. virtio-net by imposing heavy traffic while frequently changing the number of queue pairs:

iperf3 -ub0 -c $peer -t 0 & while :; do ethtool -L eth0 combined 1 ethtool -L eth0 combined 2 done

With KASAN enabled, this leads to reports like:

BUG: KASAN: slab-use-after-free in __qdisc_run+0x133f/0x1760 … Call Trace: … __qdisc_run+0x133f/0x1760 __dev_queue_xmit+0x248f/0x3550 ip_finish_output2+0xa42/0x2110 ip_output+0x1a7/0x410 ip_send_skb+0x2e6/0x480 udp_send_skb+0xb0a/0x1590 udp_sendmsg+0x13c9/0x1fc0 …

Allocated by task 1270 on cpu 5 at 44.558414s: … alloc_skb_with_frags+0x84/0x7c0 sock_alloc_send_pskb+0x69a/0x830 __ip_append_data+0x1b86/0x48c0 ip_make_skb+0x1e8/0x2b0 udp_sendmsg+0x13a6/0x1fc0 …

Freed by task 1306 on cpu 3 at 44.558445s: … kmem_cache_free+0x117/0x5e0 pfifo_fast_reset+0x14d/0x580 qdisc_reset+0x9e/0x5f0 netif_set_real_num_tx_queues+0x303/0x840 virtnet_set_channels+0x1bf/0x260 [virtio_net] ethnl_set_channels+0x684/0xae0 ethnl_default_set_doit+0x31a/0x890 …

Serialize qdisc_reset_all_tx_gt() against the lockless dequeue path by taking qdisc->seqlock for TCQ_F_NOLOCK qdiscs, matching the serialization model already used by dev_reset_queue().

Additionally clear QDISC_STATE_NON_EMPTY after reset so the qdisc state reflects an empty queue, avoiding needless re-scheduling.

Weakness

The product reuses or references memory after it has been freed. At some point afterward, the memory may be allocated again and saved in another pointer, while the original pointer references a location somewhere within the new allocation. Any operations using the original pointer are no longer valid because the memory “belongs” to the code that operates on the new pointer.

Affected Software

Potential Mitigations

References

• https://git.kernel.org/stable/c/5bb27ad54d12de67e457d7d251198e361bef835e
• https://git.kernel.org/stable/c/5bc4e69306ed7ae02232eb4c0b23ed621a26d504
• https://git.kernel.org/stable/c/7594467c49bfc2f4644dee0415ac2290db11fa0d
• https://git.kernel.org/stable/c/7f083faf59d14c04e01ec05a7507f036c965acf8
• https://git.kernel.org/stable/c/8314944cc3bdeaa5a73e6f8a8cf0d94822e625cb
• https://git.kernel.org/stable/c/c69df4e0524f8de8e176ba389acd83e85f5f49d0
• https://git.kernel.org/stable/c/dbd58b0730aa06ab6ad26079cf9a5b6b58e7e750