CVE-2026-90076 in Linux
Summary
by MITRE • 09/17/2026
In the Linux kernel, the following vulnerability has been resolved:
net/sched: fq: add overflow bounds to quantum and initial quantum
fq_init() computes quantum = 2 * psched_mtu() and initial_quantum = 10 * psched_mtu() with no overflow check. A device with a huge MTU (e.g. dummy with max_mtu == 0 accepting MTU 2147483634) makes psched_mtu() return 0x80000000; the 2 * and 10 * multiplications wrap to 0 in 32-bit arithmetic, so q->quantum == 0. Then in fq_dequeue() the credit-refill loop adds 0 to f->credit (which stays <= 0) and goto begin loops forever under the qdisc lock, creating a soft lockup.
Clamp psched_mtu() to [1, 1 << 20] before multiplying so the product
cannot wrap, then cap the result at 1 << 20, matching the bound already enforced on TCA_FQ_QUANTUM in fq_change().
Conditions to recreate the bug: a device whose MTU (plus hard_header_len) is large enough that 2 * psched_mtu() wraps (e.g. a dummy device with max_mtu == 0 accepting MTU 2147483634). Requires CAP_NET_ADMIN in a user namespace.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/17/2026
The vulnerability identified within the Linux kernel's network scheduling subsystem, specifically affecting the Fair Queueing (fq) qdisc implementation, stems from an integer overflow condition during initialization parameters calculation. The core technical flaw resides in the fq_init function, which calculates two critical variables: quantum and initial_quantum. These values are derived by multiplying the result of psched_mtu() by constants 2 and 10 respectively. In standard network configurations, these multiplications yield reasonable scheduling weights that allow fair bandwidth distribution among flows. However, when a network device is configured with an exceptionally large Maximum Transmission Unit (MTU), such as those found in dummy interfaces capable of accepting MTUs up to two billion bytes, the psched_mtu() function returns a value close to 0x80000000. When this large integer undergoes multiplication by small constants within a thirty-two-bit arithmetic context, it exceeds the maximum representable positive signed integer, causing an arithmetic wrap-around that results in zero or negative values for quantum and initial_quantum.
This overflow condition directly triggers a denial of service scenario characterized by a soft lockup within the kernel scheduler loop. Upon initialization with these corrupted parameters, the fq_dequeue function enters its credit-refill logic. The algorithm is designed to add the quantum value to a flow's credit counter until it reaches a positive threshold before allowing packet transmission. Because the overflowed quantum equals zero, the addition operation fails to increase the credit variable. Consequently, the loop condition remains perpetually true, causing the scheduler to spin indefinitely while holding the qdisc lock. This infinite loop consumes CPU resources entirely and prevents other network operations from proceeding on that queue, effectively freezing the networking stack for processes dependent on this specific device interface. The impact is severe as it leads to system instability or complete unresponsiveness regarding network traffic through the affected interface.
The exploitation of this vulnerability requires specific environmental conditions that limit its broad applicability but still pose a significant risk in containerized and virtualized environments. An attacker must possess CAP_NET_ADMIN capabilities within a user namespace, which is common for administrators managing containers or virtual machines. By creating a dummy network device with an artificially inflated MTU setting, the attacker can trigger the overflow during interface initialization. This represents a classic case of improper input validation where external configuration parameters are not adequately bounded before being used in arithmetic operations that assume safe ranges. The vulnerability aligns with CWE-190, Integer Overflow or Wraparound, as the root cause is the failure to check for arithmetic limits prior to multiplication. Furthermore, from an ATT&CK perspective, this behavior facilitates Denial of Service (T1499) by exhausting system resources through a kernel-level infinite loop, disrupting availability without requiring privilege escalation beyond existing container permissions.
Mitigation strategies focus on enforcing strict bounds checking before performing sensitive calculations within the network stack. The primary remediation involves clamping the output of psched_mtu() to a safe range, specifically between one and two million (1 << 20), prior to any multiplication operations. This ensures that even if an interface reports an excessively large MTU, the values used for scheduling weights remain within predictable limits. Additionally, the final calculated quantum should be capped at this same maximum value to maintain consistency with existing constraints enforced by TCA_FQ_QUANTUM settings in fq_change(). System administrators and developers managing network namespaces should ensure that kernel updates incorporating these bounds checks are applied promptly. For environments where dummy devices or similar virtual interfaces are used for testing or tunneling, it is advisable to manually enforce reasonable MTU limits at the configuration level as a defensive measure against potential misconfigurations or malicious intent until patches can be deployed.