CVE-2026-90075: net/sched: fq_codel: clamp default quantum and mtu
In the Linux kernel, the following vulnerability has been resolved:
net/sched: fqcodel: clamp default quantum and mtu
fqcodelinit() 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 fqcodeldequeue(), causing an infinite loop and soft lockup. Emulate fqcodelchange() and constrain to [256, FQCODELQUANTUMMAX].
The same unclamped pschedmtu() is assigned to q->cparams.mtu a bit below, and fqcodelchange() never updates it. codelshoulddrop() tests "backlog <= params->mtu"; with mtu == 0x80000000 (~2 GiB) and the default 32 MiB memorylimit, the test is always true, so CoDel is silently and completely disabled (no drops, no ECN). Declare a single clamped mtu and assign both q->quantum and q->cparams.mtu from it, which also removes the double pschedmtu() call.
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_codel)to a version that resolves this vulnerability.Patch net/sched: fq_codel: clamp default quantum and mtu
Event History
Frequently Asked Questions
Who is realistically exposed to this issue?
Systems where an attacker can obtain CAP_NET_ADMIN in a user namespace are exposed if they can create or configure a device with an extremely large MTU that causes psched_mtu() to enter the sign bit. The example given is a dummy device with max_mtu set to 0 accepting an MTU of 2147483634.
What does an attacker need to trigger the soft lockup?
The attacker needs CAP_NET_ADMIN in a user namespace and a device whose MTU plus hard_header_len wraps psched_mtu() into the sign bit. Under those conditions, the default fq_codel quantum can overflow a signed flow deficit during dequeue, producing an infinite loop and soft lockup.
Are default fq_codel settings affected?
Yes. The vulnerable initialization derives both the default quantum and CoDel MTU from the device MTU without clamping. With a value near 0x80000000, the default 32 MiB memory limit means CoDel's backlog check is always true, silently disabling drops and ECN.