CVE-2026-90072

Description

In the Linux kernel, the following vulnerability has been resolved: net/sched: sfq: clamp quantum to avoid signed overflow soft lockup sfq_init() sets q->quantum = psched_mtu(qdisc_dev(sch)) (unsigned). A device with a huge MTU (e.g. dummy with max_mtu == 0 accepting MTU 2147483634) makes psched_mtu() return 0x80000000, so slot->allot = INT_MIN and INT_MIN + INT_MIN toggles between INT_MIN and 0 forever, spinning sfq_dequeue() under the qdisc lock. Clamp the quantum to [256, 1 << 20] so the refill loop terminates. The lower bound also covers q->quantum == 0 (psched_mtu() returning 0), which spins sfq_dequeue() identically. sfq_change() already rejects a negative quantum, so only the init path was exposed. Conditions to recreate the bug: a device whose MTU (plus hard_header_len) wraps psched_mtu() into the sign bit (e.g. a dummy device with max_mtu == 0 accepting MTU 2147483634). Requires CAP_NET_ADMIN in a user namespace.

Is your site exposed to CVE-2026-90072?

Run a free security scan — no signup, results in seconds.

EPSS — Exploit Prediction

0.0022

Probability of exploitation

0.11%

Percentile rank

EPSS estimates the probability that this vulnerability will be exploited in the wild within the next 30 days. A higher score means more likely to be exploited.

References

Other References

https://git.kernel.org/stable/c/2017c355a5a1af77736cd1739fe922f69b5652dc https://git.kernel.org/stable/c/6581a82bf08ba5d4e2a6d4e3080df43315b296c4 https://git.kernel.org/stable/c/816e90057ab1879562a5b7cc688e35bb9027ae97 https://git.kernel.org/stable/c/86799499585af06a9431c9e7782658667bd62650 https://git.kernel.org/stable/c/9d782c662879c3adaaca30e05c36910ad11b9e54 https://git.kernel.org/stable/c/aeb8196ecb95146e3410f635628e6cd47352b3e5 https://git.kernel.org/stable/c/d72dbdfaeb5b9b8d884e0e036c3442754379ef74 https://git.kernel.org/stable/c/da16c31517cd2c06bb2c78c73e91ae192c01c426

Frequently Asked Questions

What is CVE-2026-90072? +

In the Linux kernel, the following vulnerability has been resolved: net/sched: sfq: clamp quantum to avoid signed overflow soft lockup sfq_init() sets q->quantum = psched_mtu(qdisc_dev(sch)) (unsigned). A device with a huge MTU (e.g. dummy with max_mtu == 0 accepting MTU 2147483634) makes psched_mtu() return 0x80000000, so slot->allot = INT_MIN and INT_MIN + INT_MIN toggles between INT_MIN and 0 forever, spinning sfq_dequeue() under the qdisc lock. Clamp the quantum to [256, 1 << 20] so the refill loop terminates. The lower bound also covers q->quantum == 0 (psched_mtu() returning 0), which spins sfq_dequeue() identically. sfq_change() already rejects a negative quantum, so only the init path was exposed. Conditions to recreate the bug: a device whose MTU (plus hard_header_len) wraps psched_mtu() into the sign bit (e.g. a dummy device with max_mtu == 0 accepting MTU 2147483634). Requires CAP_NET_ADMIN in a user namespace.

How do I check if I'm vulnerable to CVE-2026-90072? +

You can use Secably's free Website Scanner to check your website for known vulnerabilities. For infrastructure scanning, use the Port Scanner to identify exposed services that may be affected. Check the vendor advisories linked above for specific patch and version information.