CVE-2026-90058: net/sched: bound qdisc_pkt_len to prevent qdisc soft lockup
In the Linux kernel, the following vulnerability has been resolved:
net/sched: bound qdiscpktlen to prevent qdisc soft lockup
qdiscgetstab() accepts a user-supplied size table, and qdisccalculatepktlen() amplifies qdiscpktlen() through the overhead, the size-table data (u16), and sizelog (up to STABSIZELOGMAX). A crafted stab can therefore set qdiscpktlen() to ~1 GiB for an ordinary skb. Per-flow deficit schedulers such as DRR and ETS replenish one quantum per loop iteration; with a tiny quantum (1) they spin billions of times under the qdisc lock, producing a soft lockup / RCU stall as illustrated by vega@nebusec.ai.
Cap the final qdiscpktlen() to QDISCPKTLENMAX so the size-table amplification cannot drive deficit schedulers into an unbounded loop. A legitimate size table (e.g. qfq's overhead 999999999, which is handled by dropping) is still accepted.
Introduce cap QDISCPKTLENMAX (1 << 20) = 1 MiB which is well above any legitimate single-skb wire length: the largest current skb->len is GSOMAXSIZE (524280), and an ATM-style size table (53/48 cell tax) amplifies that to ~578 KB, both comfortably below 1 MiB. At the same time, 1 MiB bounds the deficit refill loop to ~1M iterations per packet with quantum=1, which completes in a few milliseconds well under the demonstrated softlockup threshold (~10^9 iterations).
Conditions to recreate the bug: - CONFIGNETSCHED=y, CONFIGNETSCHDRR=y (or CONFIGNETSCHETS=y). - Attach a DRR (or ETS) root qdisc with a crafted TCASTAB that amplifies qdiscpktlen to ~1 GiB (e.g. sizelog=15, data=[32768]). - Add a class with a tiny quantum of 1 and send one small packet; the deficit loop spins billions of times under the qdisc lock and trips the softlockup detector (panic with kernel.softlockuppanic=1). - Reachable as root or from an unprivileged user in a fresh user+net namespace (unshare -Urn) with namespace-local CAPNETADMIN.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Linux kernel net/schedto a version that resolves this vulnerability.Patch net/sched: bound qdisc_pkt_len to prevent qdisc soft lockup - Configuration
Introduce/cap qdisc_pkt_len to QDISC_PKT_LEN_MAX (1 MiB) so amplification in __qdisc_calculate_pkt_len() cannot drive deficit schedulers into an unbounded loop.
Linux kernel QDISC_PKT_LEN_MAX = (1 << 20) = 1 MiB - Compensating control
If you are using DRR or ETS in a way that permits unprivileged access with CAP_NET_ADMIN (e.g., in a fresh user+net namespace), avoid exposing qdisc configuration paths that accept user-supplied STAB size tables; restrict qdisc administration to trusted privileged users only.
Event History
Frequently Asked Questions
What conditions are needed to trigger the lockup?
An attacker must provide a crafted qdisc size table (“stab”) that greatly amplifies packet length and use a per-flow deficit scheduler such as DRR or ETS with a very small quantum, such as 1. The resulting deficit refill loop can run billions of iterations while holding the qdisc lock.
What is the practical impact on an affected system?
The condition can cause a qdisc soft lockup or an RCU stall. This is a denial-of-service condition affecting packet scheduling rather than a packet-length increase on the wire.
What does the fix change, and what should be deployed?
The fix caps the final calculated qdisc packet length at QDISC_PKT_LEN_MAX, 1 MiB, preventing size-table amplification from creating an unbounded deficit refill loop. Deploy a Linux kernel update that includes this cap; the cited stable commits contain the fix.