CVE-2026-98234

What it actually does

hhf_change() accepts an unbounded TCA_HHF_HH_FLOWS_LIMIT value that bypasses the hh_flows_current_cnt check in alloc_new_hh(), allowing an attacker-controlled number of fixed-size kzalloc(GFP_ATOMIC) allocations per spoofed heavy-hitter flow and resulting in unbounded kernel memory growth.

Why it matters to the business

Systems configured with the HHF qdisc can be driven into memory exhaustion and denial of service by an administrator-level user, disrupting network traffic shaping on Linux hosts or appliances that expose tc configuration.

How an attack unfolds

An attacker with CAP_NET_ADMIN in a user namespace issues a tc qdisc change command that sets hh_limit to a huge value such as 4294967295; the kernel stores the value without clamping. Subsequent spoofed traffic then triggers repeated alloc_new_hh() calls that each allocate memory without hitting the flow-count limit, exhausting kernel memory.

How to fix it

Upgrade the kernel to a version containing commit that applies NLA_POLICY_MAX(2*HH_FLOWS_CNT) to TCA_HHF_HH_FLOWS_LIMIT and moves the default hh_flows_limit assignment before the hhf_change() call. Reconfigure any HHF qdisc instances after the upgrade; values above the new cap are rejected with an extack message.

How to confirm the fix worked

After patching, attempt tc qdisc change with hh_limit 4294967295 and confirm the command is rejected; verify tc qdisc show reports a value no larger than 2*HH_FLOWS_CNT. Inspect the qdisc source for the NLA_POLICY_MAX line and the reordered default assignment in hhf_init().

Typical attack path

1. Obtain CAP_NET_ADMIN capability inside a user namespace on a Linux system using the HHF qdisc.
2. Run tc qdisc change (or add) with hh_limit set to a value larger than 2*HH_FLOWS_CNT.
3. Generate spoofed traffic that creates many new heavy-hitter flows.
4. Observe repeated kzalloc calls in alloc_new_hh() that are no longer rate-limited by hh_flows_current_cnt.
5. Continue traffic until kernel memory is exhausted and the system becomes unresponsive.

How to detect it

Review audit logs or command history for invocations of tc that set hh_limit to extremely large values; examine kernel memory allocation traces or slab statistics for unexpected growth of hh_flow objects after a qdisc change; look for extack rejection messages once the fix is applied.

What your security team should do

• Prioritize kernel updates on any system exposing tc or using HHF qdisc in production network paths.
• Audit existing tc configurations for custom hh_limit settings above the default of 2048 and reduce them to supported values.
• Restrict CAP_NET_ADMIN to trusted processes and namespaces only.
• Monitor kernel memory usage on hosts that perform traffic shaping with HHF.