CVE-2026-98022: net: cap tx_queue_len at S16_MAX to prevent oversized ring allocations
In the Linux kernel, the following vulnerability has been resolved:
net: cap txqueuelen at S16MAX to prevent oversized ring allocations
Several subsystems allocate ring buffers sized by dev->txqueuelen with no upper bound. An unprivileged user (via unshare -Urn) can set a huge txqueuelen and exhaust global memory with ring allocations:
- pfifofast: pfifofastinit() and pfifofastchangetxqueuelen() allocate 3 skbarray rings of txqueuelen entries each. - tun: tunqueueresize() and the queue-attach path resize ptrrings to txqueuelen on the NETDEVCHANGETXQUEUELEN notifier. - tap (macvtap/ipvtap): tapqueueresize() and tapinit() resize/init ptrrings to txqueuelen on the same notifier.
netifchangetxqueuelen() is the single entry point for IFLATXQLEN, sysfs, and the SIOCSIFTXQLEN ioctl. Cap newlen at S16MAX (32767) there so the oversized value is rejected at set time. This takes effect whether the device is up or down, before dev->txqueuelen is written, before any notifier fires, and before any ring is allocated. The "> S16MAX" check also subsumes the previous unsigned-long truncation test, and a negative ifrqlen from the ioctl lands far above the cap after conversion, so both old failure modes are covered by the one comparison.
txqueuelen 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 directqlen, qfq maxclasses, teql). 32767 is chosen as the largest value NLAPOLICYFULLRANGE can express for the u32 IFLATXQLEN 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: - CONFIGNETSCHED=y, CONFIGVETH=y, CONFIGUSERNS=y, CONFIGNETNS=y. - Unprivileged user in a fresh user+net namespace (unshare -Urn). - pfifofast: create veth pairs, set txqueuelen to 500000, attach mq+pfifofast. ~28 iterations OOMs a 2GB guest. - tun: create 50 tun devices with IFFMULTIQUEUE, set txqueuelen to 500000, open 8 queues each. ~1.6GB of ptrring allocations OOMs a 512MB guest. - tap: same as tun with IFFTAP. ~960MB OOMs a 512MB guest. - On the fixed kernel the oversized txqueuelen is rejected with -ERANGE at set time (all four paths: RTMSETLINK, RTMNEWLINK create, sysfs, ioctl - the latter two via this check, the former two via this check and the 2/3 parse policy respectively).
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.158.1-1 - Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 6.1.190-1Fixed in 6.12.115-2Fixed in 7.2.12-1Fixed in 7.2.15-1 - Upgrade
Upgrade
debian/linux-6.12to a version that resolves this vulnerability.Fixed in 6.12.113-1~deb12u1 - 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 - Configuration
Cap new tx_queue_len values at S16_MAX (32767) so oversized values are rejected with -ERANGE before the queue length is written or ring allocations occur.
Linux kernel tx_queue_len = 32767
Event History
Frequently Asked Questions
What level of access does an attacker need?
An unprivileged user can trigger the issue by using unshare -Urn to create a user and network namespace, then setting an excessively large transmit queue length.
Which networking components can allocate excessive memory?
The affected ring allocations are in pfifo_fast, tun, and tap implementations including macvtap and ipvtap. These components size skb_array or ptr_ring buffers from the device transmit queue length.
Is an interface protected by being down when its queue length is changed?
No. The queue-length limit is applied whether the device is up or down, before the new value is written and before notifiers or ring allocations occur.
How can an administrator check whether the fix is present?
Attempting to set a transmit queue length above 32767 through IFLA_TXQLEN, sysfs, or the SIOCSIFTXQLEN ioctl should be rejected at set time. A kernel that accepts such a value does not exhibit the described capped behavior.