CVE-2026-98567: net: xps: reject an out of range traffic class
In the Linux kernel, the following vulnerability has been resolved:
net: xps: reject an out of range traffic class
Only the entries below dev->numtc are valid in dev->tctotxq[], and dev->priotcmap[] may only name classes below it. netdevsetnumtc() lowers dev->numtc without touching either array.
netdevtxqtotc() walks all TCMAXQUEUE slots and netdevgetpriotcmap() returns the entry as it stands, so a leftover entry is handed out as a traffic class >= dev->numtc. Taking that class from netdevtxqtotc(), netifsetxpsqueue() rejects only a negative one and indexes an XPS map sized for dev->numtc classes:
tci = j numtc + tc; RCUINITPOINTER(newdevmaps->attrmap[tci], map);
attrmap[] holds nrids numtc entries and j runs over the ids named in the mask, so a class that is not below numtc pushes tci past the end of the map for the last ids and the store overruns it.
Any caller that lowers numtc leaves such entries behind, and mqpriodestroy() tears down with netdevsetnumtc(dev, 0) rather than netdevresettc(). After mqprio with 8 classes then 1, tctotxq[1..7] still describe txq 1..7. The splat is from an XPS write to txq 2 on a veth with 8 rx queues: attrmap[] 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 netifsetxpsqueue (net/core/dev.c:2954) Write of size 8 at addr ffff88813016bc58 by task xpsoob/634 netifsetxpsqueue (net/core/dev.c:2954) xpsrxqsstore (net/core/net-sysfs.c:1880) netdevqueueattrstore (net/core/net-sysfs.c:1390) Allocated by task 634: kmallocnoprof (mm/slub.c:5439) netifsetxpsqueue (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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 6.6.159.1-1 - Upgrade
Upgrade
azurelinux/kernelto a version that resolves this vulnerability.Fixed in 6.6.159.1-1 - Upgrade
Upgrade
ubuntu/linux-aws-5.15to a version that resolves this vulnerability.Fixed in 5.15.0-1119.126~20.04.1 - Upgrade
Upgrade
ubuntu/linux-azure-5.15to a version that resolves this vulnerability.Fixed in 5.15.0-1125.134~20.04.1 - Upgrade
Upgrade
ubuntu/linux-azure-fde-5.15to a version that resolves this vulnerability.Fixed in 5.15.0-1124.133~20.04.1 - Upgrade
Upgrade
ubuntu/linux-gcp-5.15to a version that resolves this vulnerability.Fixed in 5.15.0-1120.130~20.04.1 - Upgrade
Upgrade
ubuntu/linux-hwe-5.15to a version that resolves this vulnerability.Fixed in 5.15.0-202.212~20.04.1 - Upgrade
Upgrade
ubuntu/linux-ibm-5.15to a version that resolves this vulnerability.Fixed in 5.15.0-1113.117~20.04.1 - Upgrade
Upgrade
ubuntu/linux-intel-iotg-5.15to a version that resolves this vulnerability.Fixed in 5.15.0-1114.120~20.04.1 - Upgrade
Upgrade
ubuntu/linux-lowlatency-hwe-5.15to a version that resolves this vulnerability.Fixed in 5.15.0-197.207~20.04.1 - Upgrade
Upgrade
ubuntu/linux-nvidia-tegra-5.15to a version that resolves this vulnerability.Fixed in 5.15.0-1070.72~20.04.1 - Upgrade
Upgrade
ubuntu/linux-oracle-5.15to a version that resolves this vulnerability.Fixed in 5.15.0-1116.122~20.04.1 - Upgrade
Upgrade
ubuntu/linux-riscv-5.15to a version that resolves this vulnerability.Fixed in 5.15.0-1113.117~20.04.2 - Upgrade
Upgrade
ubuntu/linuxto a version that resolves this vulnerability.Fixed in 5.15.0-202.212 - Upgrade
Upgrade
ubuntu/linux-awsto a version that resolves this vulnerability.Fixed in 5.15.0-1119.126 - Upgrade
Upgrade
ubuntu/linux-azureto a version that resolves this vulnerability.Fixed in 5.15.0-1125.134 - Upgrade
Upgrade
ubuntu/linux-azure-fdeto a version that resolves this vulnerability.Fixed in 5.15.0-1124.133 - Upgrade
Upgrade
ubuntu/linux-gcpto a version that resolves this vulnerability.Fixed in 5.15.0-1120.130 - Upgrade
Upgrade
ubuntu/linux-gketo a version that resolves this vulnerability.Fixed in 5.15.0-1115.121 - Upgrade
Upgrade
ubuntu/linux-gkeopto a version that resolves this vulnerability.Fixed in 5.15.0-1102.110 - Upgrade
Upgrade
ubuntu/linux-ibmto a version that resolves this vulnerability.Fixed in 5.15.0-1113.117 - Upgrade
Upgrade
ubuntu/linux-intel-iotgto a version that resolves this vulnerability.Fixed in 5.15.0-1114.120 - Upgrade
Upgrade
ubuntu/linux-kvmto a version that resolves this vulnerability.Fixed in 5.15.0-1111.116 - Upgrade
Upgrade
ubuntu/linux-lowlatencyto a version that resolves this vulnerability.Fixed in 5.15.0-197.207 - Upgrade
Upgrade
ubuntu/linux-nvidiato a version that resolves this vulnerability.Fixed in 5.15.0-1114.115 - Upgrade
Upgrade
ubuntu/linux-nvidia-tegrato a version that resolves this vulnerability.Fixed in 5.15.0-1070.72 - Upgrade
Upgrade
ubuntu/linux-nvidia-tegra-igxto a version that resolves this vulnerability.Fixed in 5.15.0-1059.59 - Upgrade
Upgrade
ubuntu/linux-oracleto a version that resolves this vulnerability.Fixed in 5.15.0-1116.122 - Upgrade
Upgrade
ubuntu/linux-bluefieldto a version that resolves this vulnerability.Fixed in 5.15.0-1103.105 - Upgrade
Upgrade
ubuntu/linux-intel-iot-realtimeto a version that resolves this vulnerability.Fixed in 5.15.0-1111.115 - Upgrade
Upgrade
ubuntu/linux-realtimeto a version that resolves this vulnerability.Fixed in 5.15.0-1118.127 - Upgrade
Upgrade
ubuntu/linux-aws-fipsto a version that resolves this vulnerability.Fixed in 5.15.0-1119.126+fips1 - Upgrade
Upgrade
ubuntu/linux-azure-fipsto a version that resolves this vulnerability.Fixed in 5.15.0-1125.134+fips1 - Upgrade
Upgrade
ubuntu/linux-fipsto a version that resolves this vulnerability.Fixed in 5.15.0-202.212+fips1 - Upgrade
Upgrade
ubuntu/linux-gcp-fipsto a version that resolves this vulnerability.Fixed in 5.15.0-1120.130+fips1 - Upgrade
Upgrade
ubuntu/linux-hwe-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42~24.04.1 - Upgrade
Upgrade
ubuntu/linux-riscv-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1~24.04.1 - Upgrade
Upgrade
ubuntu/linuxto a version that resolves this vulnerability.Fixed in 7.0.0-42.42 - Upgrade
Upgrade
ubuntu/linux-awsto a version that resolves this vulnerability.Fixed in 7.0.0-1016.17 - Upgrade
Upgrade
ubuntu/linux-gcpto a version that resolves this vulnerability.Fixed in 7.0.0-1016.18 - Upgrade
Upgrade
ubuntu/linux-ibmto a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oem-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oracleto a version that resolves this vulnerability.Fixed in 7.0.0-1015.16 - Upgrade
Upgrade
ubuntu/linux-riscvto a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1 - Compensating control
In __netif_set_xps_queue(), reject any traffic class that is greater than or equal to dev->num_tc before indexing attr_map[].
- Compensating control
In mqprio_destroy(), use netdev_reset_tc() instead of netdev_set_num_tc(dev, 0) so stale traffic-class mappings are cleared.
Event History
Frequently Asked Questions
What configuration changes can leave the device in a vulnerable state?
Lowering dev->num_tc can leave stale traffic-class entries in dev->tc_to_txq[] and dev->prio_tc_map[]. The description specifically identifies mqprio teardown, which uses netdev_set_num_tc(dev, 0), and gives an example of changing from mqprio with 8 classes to 1.
What is needed to trigger the out-of-bounds write?
A stale traffic-class entry must be returned after num_tc has been reduced, followed by an XPS queue update for a transmit queue associated with that stale class. The XPS map is sized using the reduced num_tc value, so a traffic class greater than or equal to num_tc can cause attr_map[] to be indexed past its end.
What can be done if the fix cannot be applied immediately?
Avoid workflows that lower the configured number of traffic classes while retaining or subsequently modifying XPS queue mappings. In particular, avoid the described mqprio transition from multiple classes to fewer classes before writing XPS settings for queues associated with the prior configuration.
How might this issue appear during operation?
The described reproduction produces a kernel splat during an XPS write to transmit queue 2 on a veth device with 8 receive queues, after mqprio has been changed from 8 traffic classes to 1. Such a splat during XPS configuration after a traffic-class reduction is an indicator of the stale mapping condition.