CVE-2026-98022

Received Received - Intake

Memory Exhaustion via tx_queue_len in Linux Kernel

Publication date: 2026-09-25

Last updated on: 2026-10-03

Assigner: kernel.org

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

CVSS Scores

EPSS Scores

Probability:
Percentile:

Meta Information

Published

2026-09-25

Last Modified

2026-10-03

Generated

2026-10-15

AI Q&A

2026-09-25

EPSS Evaluated

2026-10-14

NVD

CVE-2026-98022

EUVD

EUVD-2026-86675

Affected Vendors & Products

Vendor	Product	Version / Range
linux	linux_kernel	to 32767 (inc)

Helpful Resources

Exploitability

CWE

KEV

CWE ID	Description
CWE-UNKNOWN

Attack-Flow Graph

Executive Summary

This vulnerability in the Linux kernel allows an unprivileged user to set an extremely large tx_queue_len value on network devices, causing excessive memory allocation for ring buffers. The issue occurs because several subsystems (pfifo_fast, tun, tap) allocate ring buffers based on tx_queue_len without an upper limit. An attacker can exploit this to exhaust system memory and trigger an out-of-memory (OOM) condition.

Detection Guidance

This vulnerability can be detected by checking if tx_queue_len is set to an unusually high value on network devices. Commands like 'ip link show' or 'cat /sys/class/net/<device>/tx_queue_len' can be used to inspect tx_queue_len values. If any device has a value exceeding 32767, it may indicate an attempt to exploit this vulnerability.

Impact Analysis

An attacker with unprivileged access could crash the system by causing an OOM condition. This leads to denial-of-service (DoS) where legitimate processes cannot allocate memory. Systems with limited memory are particularly vulnerable, and the attack can be executed without special privileges using unshare -Urn.

Compliance Impact

This vulnerability does not directly affect compliance with GDPR, HIPAA, or similar standards as it pertains to memory exhaustion in the Linux kernel's network subsystem rather than data protection or privacy. However, if exploited to cause a denial-of-service (DoS) condition, it could indirectly impact compliance by disrupting system availability, which may violate service-level agreements or operational requirements in regulated environments.

Mitigation Strategies

Immediately update the Linux kernel to a patched version where tx_queue_len is capped at 32767. Monitor network devices for unusually high tx_queue_len values and reset them to safe levels if detected. Restrict unprivileged user namespace access if not required.

Hi! I’m here to help you understand CVE-2026-98022. Ask me anything about the vulnerability, its impact, or mitigation strategies.

0/70