---
id: "CVE-2026-98567"
kind: "vulnerability"
aliases: ["CVE-2026-98567"]
title: "Linux kernel: out-of-range XPS traffic class overruns memory in network transmit setup"
severity: "unknown"
cvss: null
epss: null
exploited: false
status: "open"
category: "infrastructure"
products: []
ecosystems: []
tags: ["infrastructure", "linux-kernel", "mqprio", "networking", "self-hosted"]
not_affected_if: ["default-config"]
published_at: "2026-10-18T16:17:08+00:00"
first_seen_at: "2026-10-23T21:57:15+00:00"
updated_at: "2026-10-25T05:23:17+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-98567", "first_seen_at": "2026-10-23T21:57:15+00:00"}]
---

# Linux kernel: out-of-range XPS traffic class overruns memory in network transmit setup

After the number of traffic classes is lowered, stale per-queue entries can name a class beyond the valid range. Writing an XPS queue mapping then stores past the end of an allocated map, a kernel memory corruption that a local user with access to the queue sysfs settings may be able to trigger.

_Summary, check and fix written by a model from the sources; labelled as such._

## How to check

- unknown

## Fix

- Update the Linux kernel to a release that includes the upstream commit 'net: xps: reject an out of range traffic class'
- unknown

## Timeline

- 2026-10-23T21:57:15+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-98567

## From the sources

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.

---

_Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai_