CVE-2026-90072: net/sched: sfq: clamp quantum to avoid signed overflow soft lockup
In the Linux kernel, the following vulnerability has been resolved:
net/sched: sfq: clamp quantum to avoid signed overflow soft lockup
sfqinit() sets q->quantum = pschedmtu(qdiscdev(sch)) (unsigned). A device with a huge MTU (e.g. dummy with maxmtu == 0 accepting MTU 2147483634) makes pschedmtu() return 0x80000000, so slot->allot = INTMIN and INTMIN + INTMIN toggles between INTMIN and 0 forever, spinning sfqdequeue() under the qdisc lock.
Clamp the quantum to [256, 1 << 20] so the refill loop terminates. The lower bound also covers q->quantum == 0 (pschedmtu() returning 0), which spins sfqdequeue() identically. sfqchange() already rejects a negative quantum, so only the init path was exposed.
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.
- Configuration
Apply the net/sched sfq fix so sfq_change()/init clamps q->quantum to the range [256, 1 << 20]. This prevents signed overflow/signed-bit wrap where INT_MIN toggles with psched_mtu() into 0, which otherwise can cause a soft lockup spin in sfq_dequeue().
Linux kernel net/sched sfq q->quantum (quantum) clamping = Clamp the quantum to [256, 1 << 20]
Event History
Frequently Asked Questions
Who can trigger the soft lockup?
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 uses a dummy device with max_mtu set to 0 that accepts an MTU of 2147483634.
Is normal SFQ configuration through its change path affected?
The exposed path is SFQ initialization. The SFQ change path already rejects a negative quantum, so the issue is limited to initialization when psched_mtu() returns zero or a value that enters the sign bit.
What condition causes the lockup?
The device MTU plus hard-header length must make psched_mtu() wrap to zero or into the sign bit. This can set the SFQ quantum to zero or 0x80000000, causing sfq_dequeue() to spin under the qdisc lock.
What does the fix change?
The fix clamps the SFQ quantum to the range 256 through 1 << 20 during initialization. This prevents the refill loop from repeatedly toggling or remaining at invalid allotment values.