CVE-2026-98234
net/sched: hhf: cap hh_flows_limit at change time
No known exploitation. EPSS puts it in the 7th percentile. Fixed versions are out.
What to do
Find your product and version, then upgrade to the build on the right.
- LinuxAffected: ≥ 10239edf86f137ce4c39b62ea9575e8053c549a0, < 7adfd0a42174b85c6bd678858ecd6674f403f336Upgrade to: 7adfd0a42174b85c6bd678858ecd6674f403f336Affected: ≥ 10239edf86f137ce4c39b62ea9575e8053c549a0, < 35fd423a5c5132c6f4321f6c4f0a7b4b90af830cUpgrade to: 35fd423a5c5132c6f4321f6c4f0a7b4b90af830cAffected: ≥ 10239edf86f137ce4c39b62ea9575e8053c549a0, < 06d2a101e89063cb0b9b459104db48bdfb0a797dUpgrade to: 06d2a101e89063cb0b9b459104db48bdfb0a797dAffected: ≥ 10239edf86f137ce4c39b62ea9575e8053c549a0, < d8e2f1f0263b7c97b222c06070cccf13e0ab7112Upgrade to: d8e2f1f0263b7c97b222c06070cccf13e0ab7112 + 4 more branchesStated by: CVE record
Versions as the sources state them. Full version matrix after sign-in
What it is
From the CVE record
In the Linux kernel, the following vulnerability has been resolved: net/sched: hhf: cap hh_flows_limit at change time hhf_change() stores TCA_HHF_HH_FLOWS_LIMIT with no upper bound. A huge hh_flows_limit lets each new heavy-hitter flow pass the hh_flows_current_cnt check in alloc_new_hh() and forces a fixed-size kzalloc(GFP_ATOMIC) per flow under spoofed traffic, for unbounded memory growth. Bound the attribute with NLA_POLICY_MAX() at 2*HH_FLOWS_CNT (the hhf_init() default) and report the rejected value via extack. The deprecated nested parse is kept: legacy tc does not set NLA_F_NESTED on TCA_OPTIONS. Configs relying on hh_limit above the default were relying on unbounded, unsafe behaviour and are not supported going forward. hhf_init() also ran hhf_change() before setting the default hh_flows_limit, so a user-supplied hh_limit at add time was clobbered back to 2048. Set the default before hhf_change() so the configured value sticks. This is a follow-up to commit eb56a495f59b ("net/sched: hhf: clamp quantum in change and init paths"), which bounded the quantum of the same qdisc; the hh_flows_limit bound is the remaining unbounded knob of that series' scope. Conditions to recreate the bug: CAP_NET_ADMIN in a user namespace; tc qdisc change dev X root hhf hh_limit 4294967295 succeeds and the value is echoed by tc qdisc show, unbounding heavy-hitter flow allocations; also tc qdisc add dev X root hhf hh_limit 500 stores 2048 instead of 500.
In plain language
No plain-language summary for this CVE yet.
Exploitation
Where each signal puts this CVE on the scale from published to confirmed exploited.
- CISA KEV
Not in the catalog. CISA has not confirmed exploitation.
- Public exploits
No public exploit or proof of concept found in the sources we track.
- EPSS
0.2% chance of exploitation activity in the next 30 days, which ranks it in the 7th percentile of scored CVEs.
Exploit Prediction Scoring System, FIRST.org. A probability, not a confirmation.
Lifecycle
2 events over 0 days, from the signal feeds we watch.
- Publishedrecord updated
Affected products
Sources
References in the record
- git.kernel.org/stable/c/7adfd0a42174b85c6bd678858ecd6674f403f336
- git.kernel.org/stable/c/35fd423a5c5132c6f4321f6c4f0a7b4b90af830c
- git.kernel.org/stable/c/06d2a101e89063cb0b9b459104db48bdfb0a797d
And 5 more references. See all after sign-in
In the news
Watch the software you run.
My Stack ranks new CVEs for your products by real-world exploitation, so the next serious one reaches you without reading every advisory.
We'll flag the next CVE, public exploit or patch for Linux, not every advisory.
A free account adds
- The full version matrix and every affected product
- Exploit links, proofs of concept and Metasploit modules
- Email alerts for the products you watch
- The same data over REST API, MCP and CLI