CVE-2026-98234

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.