In the Linux kernel, the following vulnerability has been resolved: net: cap skb->queue_mapping when the tx queue is picked skbedit can set… (CVE-2026-98797)

The vulnerability involves the Linux kernel's network packet transmission path where skbedit can set skb->queue_mapping and raise a per-CPU skip_txqueue flag so __dev_queue_xmit() honors the mapping. However, __dev_queue_xmit() cleared the flag before sch_handle_egress() and only read it afterward, allowing a nested transmit (such as mirred redirect or mirror) to set the flag which the outer transmit would then consume incorrectly. This caused the outer device to index its tx queue state with a stale skb->queue_mapping value from the ingress NIC, leading to out-of-bounds access in taprio_enqueue() when indexing the taprio child qdisc array. The fix involves restricting the skip_txqueue flag to be set only within the egress classifier context inside sch_handle_egress(), saving and restoring the flag around the egress hook, and capping skb->queue_mapping to valid tx queue indices. The vulnerability can be triggered by a local user with CAP_NET_ADMIN in a network namespace redirecting packets from a device with more TX queues to one with fewer, causing a kernel slab-out-of-bounds fault under KASAN. The fix ensures the flag and queue mapping are correctly managed to prevent invalid indexing.

A local user with CAP_NET_ADMIN privileges in a network namespace can cause the kernel to perform out-of-bounds memory access in the taprio scheduler's enqueue function by redirecting packets between devices with differing numbers of TX queues. This can lead to kernel memory corruption and potential system instability or crashes. Under KASAN (Kernel Address Sanitizer), this manifests as a slab-out-of-bounds fault. There is no indication of remote exploitation or active exploitation in the wild.

A fix has been implemented in the Linux kernel to properly scope the skip_txqueue flag and cap skb->queue_mapping values, preventing out-of-bounds access. Users should update to the fixed kernel version once available. No additional mitigation is required as the patch addresses the root cause. Since this is a kernel-level issue triggered by local privileged users, limiting CAP_NET_ADMIN privileges and network namespace access can reduce exposure until patched.