CVE-2026-90072 in Linux
Summary
by MITRE • 09/17/2026
In the Linux kernel, the following vulnerability has been resolved:
net/sched: sfq: clamp quantum to avoid signed overflow soft lockup
sfq_init() sets q->quantum = psched_mtu(qdisc_dev(sch)) (unsigned). A device with a huge MTU (e.g. dummy with max_mtu == 0 accepting MTU 2147483634) makes psched_mtu() return 0x80000000, so slot->allot = INT_MIN and INT_MIN + INT_MIN toggles between INT_MIN and 0 forever, spinning sfq_dequeue() under the qdisc lock.
Clamp the quantum to [256, 1 << 20] so the refill loop terminates. The
lower bound also covers q->quantum == 0 (psched_mtu() returning 0), which spins sfq_dequeue() identically. sfq_change() already rejects a negative quantum, so only the init path was exposed.
Conditions to recreate the bug: a device whose MTU (plus hard_header_len) wraps psched_mtu() into the sign bit (e.g. a dummy device with max_mtu == 0 accepting MTU 2147483634). Requires CAP_NET_ADMIN in a user namespace.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/17/2026
The vulnerability identified within the Linux kernel's scheduling subsystem, specifically affecting the Stochastic Fairness Queueing implementation located at net/sched/sfq.c, represents a critical integer overflow issue that leads to denial of service conditions through soft lockups. This flaw originates in the sfq_init function where the quantum parameter is assigned based on the result of psched_mtu applied to the network device associated with the qdisc. The underlying technical defect arises when this calculation yields a value that, when interpreted as a signed integer for subsequent arithmetic operations, results in an underflow or overflow scenario. Specifically, if a network interface possesses an exceptionally large Maximum Transmission Unit such that psched_mtu returns 0x80000000, the resulting allotment variable becomes INT_MIN. During packet dequeueing operations, the algorithm attempts to add this value to itself repeatedly in a refill loop intended to process packets. Because adding two instances of INT_MIN results in an overflow that toggles between INT_MIN and zero depending on implementation details or compiler optimizations, the condition for terminating the loop is never met. Consequently, the sfq_dequeue function enters an infinite spin while holding the qdisc lock, effectively freezing the network processing path for that queue and causing a soft lockup that can degrade system stability or render specific network services unresponsive.
The operational impact of this vulnerability is significant as it allows a local user with appropriate privileges to disrupt network functionality without requiring physical access or remote exploitation vectors. The attack requires CAP_NET_ADMIN capabilities within a user namespace, which limits the scope primarily to users who have been granted administrative rights over their own network namespaces but do not necessarily possess full root privileges on the host system. This scenario is common in containerized environments where containers are given limited networking controls for configuration purposes. By configuring a dummy device with an extreme MTU value such as 2147483634, which exceeds standard Ethernet limits and triggers the specific arithmetic boundary condition, an attacker can induce the kernel to hang indefinitely on packet processing tasks associated with that qdisc. This denial of service affects not only the affected network namespace but potentially impacts other processes sharing the same CPU resources due to the spinning lock preventing normal scheduler progression for those threads.
From a classification perspective, this vulnerability aligns closely with CWE-190 Integer Overflow or Wraparound and CWE-835 Loop with Unreachable Exit Condition which describes scenarios where loops fail to terminate due to logical errors in boundary conditions. In terms of adversary behavior mapping under the MITRE ATT&CK framework, this exploit technique corresponds to T1499 Endpoint Denial of Service specifically involving resource exhaustion through infinite loops or kernel panics triggered by malformed configuration inputs. The root cause lies in insufficient input validation and range checking during the initialization phase rather than during runtime changes, as evidenced by the fact that sfq_change already rejects negative quantum values but fails to clamp positive extremes that lead to signed interpretation issues.
Mitigation strategies for this vulnerability involve both immediate patching of the kernel source code and broader operational security practices. The primary remediation is applying the upstream Linux kernel fix which clamps the quantum value to a safe range between 256 and one megabyte, thereby ensuring that arithmetic operations remain within valid signed integer bounds and guarantee loop termination regardless of device MTU settings. System administrators should ensure their kernels are updated with patches addressing this specific net/sched sfq issue. Additionally, organizations employing containerization or network namespaces should enforce strict least-privilege principles regarding CAP_NET_ADMIN capabilities to limit the potential attack surface for users who might attempt to configure extreme interface parameters. Regular auditing of network device configurations and monitoring for signs of soft lockups in system logs can also aid in early detection and response to such exploitation attempts before they cause widespread service disruption.