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.
Published: 2026-10-06
Score: n/a
EPSS: n/a
KEV: No
Impact: Denial of Service (unbounded memory allocation)
Action: Apply Patch
AI Analysis

Impact

hhf_change() in the Linux kernel stored the hh_flows_limit attribute without any upper bound. A user with CAP_NET_ADMIN in a user namespace can set an arbitrarily large hh_limit value via `tc qdisc change`, which then allows each new heavy‑hitter flow to bypass the flow count check and allocate a fixed‑size, atomically allocated memory block per flow. Because the limit is unbounded, an attacker can trigger unbounded memory consumption, leading to kernel out‑of‑memory conditions and a denial of service.

Affected Systems

The vulnerability affects the Linux kernel’s traffic‑control (tc) subsystem, specifically the hhf qdisc implementation. All Linux‑kernel releases that include this qdisc code are potentially impacted unless the patch has been applied; no specific kernel version is listed in the advisory.

Risk and Exploitability

The risk is significant for hosts that grant CAP_NET_ADMIN to users or processes, as the unbounded hh_flows_limit can be exploited by a privileged local attacker or within a container with elevated privileges. The advisory does not list the CVE in the CISA KEV catalog and EPSS data is unavailable, but the lack of an upper bound combined with the privileged execution path suggests substantial exploitability. The CVSS score is not provided, yet the potential for kernel memory exhaustion and system crash justifies treating the vulnerability as high severity.

Generated by OpenCVE AI on October 6, 2026 at 11:58 UTC.

Remediation

No solution or workaround provided in the CVE record.

OpenCVE Recommended Actions

  • Apply the kernel patch that bounds hh_flows_limit and sets the default before hhf_change (any Linux kernel version that includes commit 06d2a101e890... or later).
  • If patching immediately is not possible, configure the hhf qdisc to use a bounded hh_limit (e.g., 2048) and avoid setting values above the default.
  • Restrict CAP_NET_ADMIN privileges to trusted administrators only, and audit any containers or services that may obtain this capability.

Generated by OpenCVE AI on October 6, 2026 at 11:58 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Tue, 06 Oct 2026 12:15:00 +0000

Type Values Removed Values Added
Weaknesses CWE-188

Tue, 06 Oct 2026 09:00:00 +0000

Type Values Removed Values Added
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.
Title net/sched: hhf: cap hh_flows_limit at change time
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-10-06T08:45:07.215Z

Reserved: 2026-09-25T10:25:14.329Z

Link: CVE-2026-98234

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Received

Published: 2026-10-06T09:18:11.033

Modified: 2026-10-06T09:18:11.033

Link: CVE-2026-98234

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-10-06T12:00:15Z

Weaknesses
  • CWE-188

    Reliance on Data/Memory Layout