Linux Kernel up to 7.2.5 Qdisc net/sched qdisc_get_stab TCA_STAB infinite loop

| CVSS Meta Temp Score | Current Exploit Price (≈) | CTI Interest Score |
|---|---|---|
| 4.7 | $0-$5k | 0.00 |
Summary
A vulnerability was found in Linux Kernel up to 7.2.5. It has been classified as problematic. This affects the function qdisc_get_stab of the file net/sched of the component Qdisc. Performing a manipulation of the argument TCA_STAB results in infinite loop.
This vulnerability is identified as CVE-2026-90058. The attack can be initiated remotely. There is not any exploit available.
Upgrading the affected component is recommended.
Details
A vulnerability, which was classified as problematic, was found in Linux Kernel up to 7.2.5. This affects the function qdisc_get_stab of the file net/sched of the component Qdisc. The manipulation of the argument TCA_STAB with an unknown input leads to a infinite loop vulnerability. CWE is classifying the issue as CWE-835. The product contains an iteration or loop with an exit condition that cannot be reached, i.e., an infinite loop. This is going to have an impact on availability. The summary by CVE is:
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 [email protected]. 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.
It is possible to read the advisory at git.kernel.org. This vulnerability is uniquely identified as CVE-2026-90058 since 09/11/2026. The exploitability is told to be easy. It is possible to initiate the attack remotely. The exploitation needs additional levels of successful authentication. Technical details of the vulnerability are known, but there is no available exploit. The attack technique deployed by this issue is T1499 according to MITRE ATT&CK.
Upgrading to version 5.10.270, 5.15.221, 6.1.188, 6.6.157, 6.12.110, 6.18.52, 7.2.6 or 7.3-rc1 eliminates this vulnerability. Applying the patch 4f0f4b09a95ef602fbdae948326beadd9c20eab3/0bc5a6280a132a2170c6fa742436e01b635f02de/448c34421b38ec7c93a0060a885218ca319d382b/82fdbf49b9f7528c82bf608cfa9710e5f81a198c/6e78792d8ce1fa3561713860ee8086901dde4f99/1a5c26e586481bc82abc19ac92c3d9f10518f525/16d21a27df3f50b7251c9388fc5a7ab22703b469/8f735d64382dcf162f4276d6699d03ad2f859c0b is able to eliminate this problem. The best possible mitigation is suggested to be upgrading to the latest version.
Be aware that VulDB is the high quality source for vulnerability data.
Product
Type
Vendor
Name
Version
- 5.10.269
- 5.15.220
- 6.1.187
- 6.6.156
- 6.12.109
- 6.18.0
- 6.18.1
- 6.18.2
- 6.18.3
- 6.18.4
- 6.18.5
- 6.18.6
- 6.18.7
- 6.18.8
- 6.18.9
- 6.18.10
- 6.18.11
- 6.18.12
- 6.18.13
- 6.18.14
- 6.18.15
- 6.18.16
- 6.18.17
- 6.18.18
- 6.18.19
- 6.18.20
- 6.18.21
- 6.18.22
- 6.18.23
- 6.18.24
- 6.18.25
- 6.18.26
- 6.18.27
- 6.18.28
- 6.18.29
- 6.18.30
- 6.18.31
- 6.18.32
- 6.18.33
- 6.18.34
- 6.18.35
- 6.18.36
- 6.18.37
- 6.18.38
- 6.18.39
- 6.18.40
- 6.18.41
- 6.18.42
- 6.18.43
- 6.18.44
- 6.18.45
- 6.18.46
- 6.18.47
- 6.18.48
- 6.18.49
- 6.18.50
- 6.18.51
- 7.2.0
- 7.2.1
- 7.2.2
- 7.2.3
- 7.2.4
- 7.2.5
License
Website
- Vendor: https://www.kernel.org/
CPE 2.3
CPE 2.2
CVSSv4
VulDB Vector: 🔒VulDB Reliability: 🔍
CVSSv3
VulDB Meta Base Score: 4.9VulDB Meta Temp Score: 4.7
VulDB Base Score: 4.9
VulDB Temp Score: 4.7
VulDB Vector: 🔒
VulDB Reliability: 🔍
CVSSv2
| AV | AC | Au | C | I | A |
|---|---|---|---|---|---|
| 💳 | 💳 | 💳 | 💳 | 💳 | 💳 |
| 💳 | 💳 | 💳 | 💳 | 💳 | 💳 |
| 💳 | 💳 | 💳 | 💳 | 💳 | 💳 |
| Vector | Complexity | Authentication | Confidentiality | Integrity | Availability |
|---|---|---|---|---|---|
| Unlock | Unlock | Unlock | Unlock | Unlock | Unlock |
| Unlock | Unlock | Unlock | Unlock | Unlock | Unlock |
| Unlock | Unlock | Unlock | Unlock | Unlock | Unlock |
VulDB Base Score: 🔒
VulDB Temp Score: 🔒
VulDB Reliability: 🔍
Exploiting
Class: Infinite loopCWE: CWE-835 / CWE-404
CAPEC: 🔒
ATT&CK: 🔒
Physical: No
Local: No
Remote: Yes
Availability: 🔒
Status: Not defined
Price Prediction: 🔍
Current Price Estimation: 🔒
| 0-Day | Unlock | Unlock | Unlock | Unlock |
|---|---|---|---|---|
| Today | Unlock | Unlock | Unlock | Unlock |
Threat Intelligence
Interest: 🔍Active Actors: 🔍
Active APT Groups: 🔍
Countermeasures
Recommended: UpgradeStatus: 🔍
0-Day Time: 🔒
Upgrade: Kernel 5.10.270/5.15.221/6.1.188/6.6.157/6.12.110/6.18.52/7.2.6/7.3-rc1
Patch: 4f0f4b09a95ef602fbdae948326beadd9c20eab3/0bc5a6280a132a2170c6fa742436e01b635f02de/448c34421b38ec7c93a0060a885218ca319d382b/82fdbf49b9f7528c82bf608cfa9710e5f81a198c/6e78792d8ce1fa3561713860ee8086901dde4f99/1a5c26e586481bc82abc19ac92c3d9f10518f525/16d21a27df3f50b7251c9388fc5a7ab22703b469/8f735d64382dcf162f4276d6699d03ad2f859c0b
Timeline
09/11/2026 CVE reserved09/17/2026 Advisory disclosed
09/17/2026 VulDB entry created
09/17/2026 VulDB entry last update
Sources
Vendor: kernel.orgAdvisory: git.kernel.org
Status: Confirmed
CVE: CVE-2026-90058 (🔒)
GCVE (CVE): GCVE-0-2026-90058
GCVE (VulDB): GCVE-100-406551
Entry
Created: 09/17/2026 18:37Changes: 09/17/2026 18:37 (61)
Complete: 🔍
Cache ID: 216::103
Be aware that VulDB is the high quality source for vulnerability data.
No comments yet. Languages: en.
Please log in to comment.