CVE-2026-98234: net/sched: hhf: cap hh_flows_limit at change time

In the Linux kernel, the following vulnerability has been resolved:

net/sched: hhf: cap hhflowslimit at change time

hhfchange() stores TCAHHFHHFLOWSLIMIT with no upper bound. A huge hhflowslimit lets each new heavy-hitter flow pass the hhflowscurrentcnt check in allocnewhh() and forces a fixed-size kzalloc(GFPATOMIC) per flow under spoofed traffic, for unbounded memory growth.

Bound the attribute with NLAPOLICYMAX() at 2HHFLOWSCNT (the hhfinit() default) and report the rejected value via extack. The deprecated nested parse is kept: legacy tc does not set NLAFNESTED on TCAOPTIONS. Configs relying on hhlimit above the default were relying on unbounded, unsafe behaviour and are not supported going forward.

hhfinit() also ran hhfchange() before setting the default hhflowslimit, so a user-supplied hhlimit at add time was clobbered back to 2048. Set the default before hhfchange() 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 hhflowslimit bound is the remaining unbounded knob of that series' scope.

Conditions to recreate the bug: CAPNETADMIN in a user namespace; tc qdisc change dev X root hhf hhlimit 4294967295 succeeds and the value is echoed by tc qdisc show, unbounding heavy-hitter flow allocations; also tc qdisc add dev X root hhf hhlimit 500 stores 2048 instead of 500.