PT-2026-98685 · Linux · Linux
CVE-2026-98022
·
Published
2026-09-25
·
Updated
2026-09-25
None
No severity ratings or metrics are available. When they are, we'll update the corresponding info on the page.
In the Linux kernel, the following vulnerability has been resolved:
net: cap tx queue len at S16 MAX to prevent oversized ring allocations
Several subsystems allocate ring buffers sized by dev->tx queue len
with no upper bound. An unprivileged user (via unshare -Urn) can set a
huge tx queue len and exhaust global memory with ring allocations:
- pfifo fast: pfifo fast init() and pfifo fast change tx queue len() allocate 3 skb array rings of tx queue len entries each.
- tun: tun queue resize() and the queue-attach path resize ptr rings to tx queue len on the NETDEV CHANGE TX QUEUE LEN notifier.
- tap (macvtap/ipvtap): tap queue resize() and tap init() resize/init ptr rings to tx queue len on the same notifier.
netif change tx queue len() is the single entry point for IFLA TXQLEN,
sysfs, and the SIOCSIFTXQLEN ioctl. Cap new len at S16 MAX (32767)
there so the oversized value is rejected at set time. This takes
effect whether the device is up or down, before dev->tx queue len is
written, before any notifier fires, and before any ring is allocated.
The "> S16 MAX" check also subsumes the previous unsigned-long
truncation test, and a negative ifr qlen from the ioctl lands far
above the cap after conversion, so both old failure modes are covered
by the one comparison.
tx queue len is ambigious: both a per-ring sizing multiplier and a
default queue-length/limit knob for consumers that allocate
nothing at set time (pfifo/bfifo/gred/plug/sfb limits, htb
direct qlen, qfq max classes, teql). 32767 is chosen as the largest
value NLA POLICY FULL RANGE can express for the u32 IFLA TXQLEN
policy in patch 2/3 while staying a legitimate queue length on
high-BDP paths; the ring-memory trade-off of a shared knob is
disclosed below.
Conditions to recreate the bug:
- CONFIG NET SCHED=y, CONFIG VETH=y, CONFIG USER NS=y, CONFIG NET NS=y.
- Unprivileged user in a fresh user+net namespace (unshare -Urn).
- pfifo fast: create veth pairs, set tx queue len to 500000, attach mq+pfifo fast. ~28 iterations OOMs a 2GB guest.
- tun: create 50 tun devices with IFF MULTI QUEUE, set tx queue len to 500000, open 8 queues each. ~1.6GB of ptr ring allocations OOMs a 512MB guest.
- tap: same as tun with IFF TAP. ~960MB OOMs a 512MB guest.
- On the fixed kernel the oversized tx queue len is rejected with -ERANGE at set time (all four paths: RTM SETLINK, RTM NEWLINK create, sysfs, ioctl - the latter two via this check, the former two via this check and the 2/3 parse policy respectively).
Found an issue in the description? Have something to add? Feel free to write us 👾
Related Identifiers
Affected Products
Linux