CVE-2026-98022

Overview

CVE-2026-98022 is a medium severity kernel vulnerability that allows an unprivileged user to set an excessively large tx_queue_len value, causing the kernel to allocate oversized ring buffers and exhaust memory. The flaw exists in several network subsystems (pfifo_fast, tun, tap, etc.) and was fixed by capping tx_queue_len at 32767. This can lead to out‑of‑memory conditions and potential denial of service.

Description

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).

Impact

Confidentiality: none. Integrity: none. Availability: high due to OOM causing service disruption. Impacted parties: system administrators, cloud hosts, virtualized environments where unprivileged users can create network namespaces.

Remediation

Apply the kernel patch that caps tx_queue_len at 32767. Ensure kernel is updated to a version where CVE-2026-98022 is fixed. Disable or restrict unshare -Urn or network namespace creation for unprivileged users. Monitor memory usage for sudden spikes in network subsystem ring allocations.

Risk context

The vulnerability has a CVSS v3 score of 5.5 and is considered medium severity. No EPSS data is available. The issue can lead to memory exhaustion and denial of service, but requires an unprivileged user to create a network namespace and set a large tx_queue_len value. Defenders should patch promptly to mitigate potential OOM attacks.

Affected products

• Linux kernel