CVE-2026-98234

/// Technical 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 ("

/// Remediation

Check the references section for vendor advisories, patches, and mitigation guidance. If immediate patching is not possible, review the CVSS vector to understand the attack surface and apply compensating controls such as network segmentation or access restrictions.

/// References