CVE-2026-98022

A flaw was found in the Linux kernel. Multiple network subsystems allocate memory buffers based on the transmit queue length without enforcing an upper bound. A local unprivileged user can exploit this vulnerability by configuring an excessively large queue length on network devices, exhausting system memory and causing a Denial of Service (DoS).

A moderate-impact denial-of-service vulnerability exists in the Linux kernel as shipped in Red Hat Enterprise Linux. Several networking subsystems (pfifo_fast, tun, and tap/macvtap/ipvtap) size ring buffer allocations from the per-device transmit queue length (dev->tx_queue_len) without enforcing an upper bound. A local unprivileged attacker who can create user and network namespaces (for example via unshare -Urn) can set an arbitrarily large transmit queue length through netlink, sysfs, or the SIOCSIFTXQLEN ioctl and repeatedly create or reconfigure network devices, exhausting global kernel memory and causing an out-of-memory denial of service. Confidentiality and integrity are not affected; the Red Hat severity is MODERATE with a CVSS 3.1 score of 5.5 (AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H). Red Hat Enterprise Linux 8, 9, and 10 (including kernel-rt), Red Hat In-Vehicle OS 2, and the RHEL CoreOS layers of OpenShift Container Platform 4 and 5 are recorded as affected, with the fix deferred to a future scheduled kernel update; until such an update ships, the residual risk is that any host allowing unprivileged local users to create user and network namespaces can be memory-exhausted and rendered unavailable. Red Hat Enterprise Linux 7 is not affected because the vulnerable code is not present in that stream, and Red Hat Enterprise Linux 6 is out of support scope for this issue.

The CVSS score(s) listed for this vulnerability do not reflect the associated product's status, and are included for informational purposes to better understand the severity of this vulnerability.

The unprivileged attack path documented upstream depends on an unprivileged local user creating a user and network namespace (unshare -Urn) to gain the ability to configure network devices. As a workaround, unprivileged creation of user namespaces can be restricted, for example by setting the sysctl user.max_user_namespaces=0, which prevents unprivileged local users from triggering this issue. Note that this can disrupt software that relies on unprivileged user namespaces, including some container configurations, and it does not prevent misuse by users who already hold network administration privileges (CAP_NET_ADMIN) on the host.