CVE-2026-90076: net/sched: fq: add overflow bounds to quantum and initial quantum
In the Linux kernel, the following vulnerability has been resolved:
net/sched: fq: add overflow bounds to quantum and initial quantum
fqinit() computes quantum = 2 pschedmtu() and initialquantum = 10 pschedmtu() with no overflow check. A device with a huge MTU (e.g. dummy with maxmtu == 0 accepting MTU 2147483634) makes pschedmtu() return 0x80000000; the 2 and 10 multiplications wrap to 0 in 32-bit arithmetic, so q->quantum == 0. Then in fqdequeue() 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 pschedmtu() to [1, 1 << 20] before multiplying so the product cannot wrap, then cap the result at 1 << 20, matching the bound already enforced on TCAFQQUANTUM in fqchange().
Conditions to recreate the bug: a device whose MTU (plus hardheaderlen) is large enough that 2 pschedmtu() wraps (e.g. a dummy device with maxmtu == 0 accepting MTU 2147483634). Requires CAPNETADMIN in a user namespace.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 6.12.111-1 - Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 7.2.6-1 - Upgrade
Upgrade
debian/linux-6.12to a version that resolves this vulnerability.Fixed in 6.12.111-1~deb12u1 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.1.191 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.6.160 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.12.110 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.18.52 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 7.2.6 - Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 6.12.115-2Fixed in 7.2.12-1Fixed in 7.2.15-1 - Upgrade
Upgrade
debian/linux-6.12to a version that resolves this vulnerability.Fixed in 6.12.113-1~deb12u1 - Upgrade
Upgrade
ubuntu/linux-hwe-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42~24.04.1 - Upgrade
Upgrade
ubuntu/linux-riscv-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1~24.04.1 - Upgrade
Upgrade
ubuntu/linuxto a version that resolves this vulnerability.Fixed in 7.0.0-42.42 - Upgrade
Upgrade
ubuntu/linux-awsto a version that resolves this vulnerability.Fixed in 7.0.0-1016.17 - Upgrade
Upgrade
ubuntu/linux-gcpto a version that resolves this vulnerability.Fixed in 7.0.0-1016.18 - Upgrade
Upgrade
ubuntu/linux-ibmto a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oem-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oracleto a version that resolves this vulnerability.Fixed in 7.0.0-1015.16 - Upgrade
Upgrade
ubuntu/linux-riscvto a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1 - Compensating control
In the Linux kernel fq qdisc implementation, clamp psched_mtu() to the range [1, 1 << 20] before calculating quantum and initial_quantum, then cap the resulting values at 1 << 20 to prevent integer overflow.
Event History
Frequently Asked Questions
Who can trigger the soft lockup?
An attacker needs CAP_NET_ADMIN in a user namespace. They also need access to a device that accepts an exceptionally large MTU, such as a dummy device with max_mtu set to 0.
Is a normal MTU configuration affected?
The issue requires an MTU plus hard-header length large enough for twice the scheduler MTU value to wrap in 32-bit arithmetic. The provided example uses an MTU of 2147483634, so ordinary MTU values do not meet the stated trigger condition.
What happens when exploitation succeeds?
The fq qdisc quantum becomes zero. During dequeue, the credit refill loop cannot make progress and loops indefinitely while holding the qdisc lock, causing a soft lockup.
What mitigation is available if the fix cannot be applied immediately?
Restrict CAP_NET_ADMIN in user namespaces and prevent creation or configuration of devices with extremely large MTUs. The affected condition depends on setting an MTU large enough to cause the quantum calculation to wrap.