CVE-2026-90074: net/sched: fq_pie: clamp default quantum to avoid signed overflow
In the Linux kernel, the following vulnerability has been resolved:
net/sched: fqpie: clamp default quantum to avoid signed overflow
fqpieinit() sets q->quantum = pschedmtu(qdiscdev(sch)) without clamping. A device with a huge MTU (e.g. dummy with maxmtu == 0 accepting MTU 2147483634) makes pschedmtu() return 0x80000000, which overflows the signed flow->deficit to INTMIN in fqpieqdiscdequeue(), causing an infinite loop and soft lockup. Emulate fqpiepolicy which is already bounded to [1, 1 << 20]; clamp the default to [256, 1 << 20]. 256 matches fqcodel's floor and is a sane minimum for a DRR quantum.
Conditions to recreate the bug: a device whose MTU (plus hardheaderlen) wraps pschedmtu() into the sign bit (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
Linux kernel (net/sched: fq_pie)to a version that resolves this vulnerability.Patch net/sched: fq_pie: clamp default quantum to avoid signed overflow - Configuration
Apply the kernel fix described: clamp fq_pie default quantum to [256, 1 << 20] to avoid signed overflow (signed flow->deficit to INT_MIN) and the related psched_mtu() wrap/signed overflow leading to infinite loop/soft lockup when extremely large MTUs (e.g., 2147483634) are accepted.
Linux fq_pie qdisc flow->deficit quantum clamping (default quantum) = Clamp the default quantum to the range [256, 1 << 20]
Event History
Frequently Asked Questions
Who can trigger this issue in practice?
An attacker needs CAP_NET_ADMIN in a user namespace and must be able to configure a device with an exceptionally large MTU. The example given is a dummy device with max_mtu set to 0 that accepts an MTU of 2147483634.
What configuration causes the failure?
The issue requires the device MTU plus hard_header_len to make psched_mtu() wrap into the sign bit. Under that condition, fq_pie can initialize its default quantum to 0x80000000, causing a signed deficit overflow during dequeue.
What is the operational impact if exploitation succeeds?
The signed overflow can cause an infinite loop in fq_pie_qdisc_dequeue(), resulting in a soft lockup.
What mitigation is available if the fix cannot be applied immediately?
Restrict untrusted users from obtaining CAP_NET_ADMIN in user namespaces and prevent creation or configuration of devices with MTUs large enough to wrap psched_mtu() into the sign bit.