CVE-2026-98234 net/sched: hhf: cap hh_flows_limit at change time
A local attacker with CAP_NET_ADMIN can cause unbounded memory growth and denial of service by setting an excessive hh_flows_limit in the HHF qdisc.
- Exploited in the wild
- Not known
- Login needed
- An administrator
- Attackable
- Local or same network only
- Victim action needed
- Not needed
- Fix
- Available
What is CVE-2026-98234?
CVE-2026-98234 is a denial of service vulnerability in Linux, published on 6 Oct 2026. It can only be exploited from the same machine or local network, with no action from the victim.
Official description
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.
Which versions are affected by CVE-2026-98234?
How do I fix CVE-2026-98234?
Apply the vendor's patch.
Upgrade, then put limits on request size, rate and nesting depth so one client cannot exhaust the service. More about Denial of service.
Is CVE-2026-98234 being exploited?
There is no known exploitation of CVE-2026-98234 in the wild and no public exploit code.
Sources
Also known as AZL-106107, BELL-CVE-2026-98234, DEBIAN-CVE-2026-98234, GHSA-qgx8-c46g-4vmq, UBUNTU-CVE-2026-98234.