CVE-2026-98567 in Linux
Summary
by MITRE • 10/18/2026
In the Linux kernel, the following vulnerability has been resolved:
net: xps: reject an out of range traffic class
Only the entries below dev->num_tc are valid in dev->tc_to_txq[], and
dev->prio_tc_map[] may only name classes below it. netdev_set_num_tc()
lowers dev->num_tc without touching either array.
netdev_txq_to_tc() walks all TC_MAX_QUEUE slots and netdev_get_prio_tc_map() returns the entry as it stands, so a leftover entry is handed out as a traffic class >= dev->num_tc. Taking that class from netdev_txq_to_tc(), __netif_set_xps_queue() rejects only a negative one and indexes an XPS map sized for dev->num_tc classes:
tci = j * num_tc + tc; RCU_INIT_POINTER(new_dev_maps->attr_map[tci], map);
attr_map[] holds nr_ids * num_tc entries and j runs over the ids named
in the mask, so a class that is not below num_tc pushes tci past the end of the map for the last ids and the store overruns it.
Any caller that lowers num_tc leaves such entries behind, and mqprio_destroy() tears down with netdev_set_num_tc(dev, 0) rather than netdev_reset_tc(). After mqprio with 8 classes then 1, tc_to_txq[1..7]
still describe txq 1..7. The splat is from an XPS write to txq 2 on a veth with 8 rx queues: attr_map[] has 8 * 1 entries, tci = j + 2, and
j == 6 stores one past the end of the 88-byte map:
BUG: KASAN: slab-out-of-bounds in __netif_set_xps_queue (net/core/dev.c:2954) Write of size 8 at addr ffff88813016bc58 by task xps_oob/634 __netif_set_xps_queue (net/core/dev.c:2954) xps_rxqs_store (net/core/net-sysfs.c:1880) netdev_queue_attr_store (net/core/net-sysfs.c:1390) Allocated by task 634: __kmalloc_noprof (mm/slub.c:5439) __netif_set_xps_queue (net/core/dev.c:2937) The buggy address is located 0 bytes to the right of allocated 88-byte region [ffff88813016bc00, ffff88813016bc58)
Reject a class the map has no room for.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/19/2026
The Linux kernel network subsystem contains an out-of-bounds write vulnerability within the XPS (Transmit Packet Steering) configuration logic, specifically in the __netif_set_xps_queue function. This flaw arises from insufficient validation of traffic classes when modifying queue mappings via sysfs interfaces. The root cause lies in a mismatch between how device traffic class configurations are managed and how they are consumed by the XPS subsystem. When network devices configure multiple traffic classes using netdev_set_num_tc, the kernel updates dev->num_tc to reflect the current number of valid classes but does not automatically clear or reset the underlying tc_to_txq[] and prio_tc_map[] arrays. This design choice allows stale entries from previously configured higher numbers of traffic classes to persist in memory even after the active count is reduced.
The vulnerability manifests when a user-space application attempts to write XPS queue mappings through netdev_queue_attr_store, which invokes __netif_set_xps_queue. This function calculates an index tci using the formula j num_tc + tc, where j represents an identifier from a mask and tc is the traffic class derived from dev->tc_to_txq[] or prio_tc_map[]. Because these arrays may contain leftover values greater than or equal to the current dev->num_tc, the calculated tci can exceed the bounds of the attr_map array. The attr_map array is allocated with size nr_ids num_tc, meaning it only accommodates traffic classes strictly less than num_tc. When a stale high-value traffic class is used in this calculation, the resulting index points beyond the end of the allocated slab region, leading to an out-of-bounds write operation that corrupts adjacent kernel memory structures.
This issue was particularly triggered by interactions with the mqprio (multi-queue priority) qdisc implementation. The mqprio_destroy function calls netdev_set_num_tc(dev, 0) rather than netdev_reset_tc(), which would properly clear all associated mappings. Consequently, if a device previously configured eight traffic classes and is later reduced to one class, entries at indices one through seven in tc_to_txq remain populated with their previous queue associations. When an XPS write operation targets any of these residual queues on a veth interface with multiple receive queues, the kernel computes an invalid index that exceeds the allocated map size. The resulting slab-out-of-bounds error indicates a write of eight bytes past the end of an 88-byte allocation, demonstrating direct memory corruption potential.
From a security perspective, this vulnerability is classified under CWE-787: Out-of-bounds Write and aligns with ATT&CK technique T1059.006: Command and Scripting Interpreter via sysfs manipulation if exploited by local users to escalate privileges or destabilize the system. The ability to write beyond allocated kernel memory boundaries can lead to arbitrary code execution, denial of service through kernel panic, or information disclosure depending on what data resides in adjacent memory regions. Attackers with access to network namespace controls and sysfs write permissions could exploit this flaw by carefully crafting traffic class configurations that trigger the out-of-bounds condition during XPS queue mapping updates.
Mitigation requires ensuring that any reduction in dev->num_tc is accompanied by a complete reset of dependent arrays such as tc_to_txq[] and prio_tc_map[]. The fix involves adding validation within __netif_set_xps_queue to reject traffic classes that are not strictly less than the current num_tc value, thereby preventing invalid indices from being computed. Additionally, developers should review other code paths that modify dev->num_tc to ensure they also clear stale entries or utilize netdev_reset_tc where appropriate to maintain consistency between logical configuration and underlying data structures. System administrators can mitigate risk by restricting sysfs write access for network device attributes to trusted users until patches are applied in updated kernel versions.