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

net/sched: hhf: clamp quantum before hhf_change() to avoid overflow

hhf_init() sets q->quantum = psched_mtu(qdisc_dev(sch)) with no overflow
check. A device with a huge MTU (e.g. dummy with max_mtu == 0 accepting
MTU 2147483634) makes weight * quantum overflow the signed deficit in
hhf_dequeue(), spinning forever.

Clamp q->quantum before hhf_change() so both the opt and !opt paths see
a sane quantum. Without this, bare "tc qdisc add ... hhf" succeeds with
a clamped quantum but "tc qdisc add ... hhf limit 1000" (any option
present) fails with -EINVAL because hhf_change() re-validates the
unclamped default (sch_hhf.c:559). 256 matches fq_codel's floor and is
a sane minimum for a DRR quantum.

Conditions to recreate the bug: a device whose MTU (plus
hard_header_len) wraps psched_mtu() into the sign bit (e.g. a dummy
device with max_mtu == 0 accepting MTU 2147483634). Requires
CAP_NET_ADMIN in a user namespace.
Published: 2026-09-17
Score: n/a
EPSS: < 1% Very Low
KEV: No
Impact: Denial of Service
Action: Patch
AI Analysis

Impact

The flaw allows an integer overflow when calculating the quantum value for a traffic‑control qdisc, causing the kernel to enter an endless loop in the dequeue routine. The overflow occurs only when a network device advertises an extremely large MTU, leading to a signed multiplication that exceeds bounds and spins the system forever, effectively denying service for that process or potentially the whole machine.

Affected Systems

All Linux kernel versions prior to the fix are vulnerable. The issue manifests when a user with CAP_NET_ADMIN adds an hhf qdisc to any device, especially dummy interfaces that can report MTUs close to the signed integer limit. The affected code applies to the core scheduler and is not tied to a particular distribution version, so any kernel build that did not apply the patch is at risk.

Risk and Exploitability

The EPSS score is reported as less than 1 percent, indicating a very low likelihood of exploitation in the wild, and the vulnerability is not listed in the CISA KEV catalog. Because the attack requires elevated kernel privileges (CAP_NET_ADMIN) in a user namespace, the practical attack surface is limited to privileged users or compromised services that can manipulate network qdiscs. Nonetheless, the impact of an infinite loop is severe, as it can consume CPU resources indefinitely and disrupt kernel scheduling.

Generated by OpenCVE AI on September 20, 2026 at 03:48 UTC.

Remediation

No solution or workaround provided in the CVE record.

OpenCVE Recommended Actions

  • Upgrade the operating system to a kernel version that includes the patch which clamps the quantum value before calling hhf_change
  • Avoid adding hhf qdiscs to dummy or other interfaces capable of reporting extremely large MTUs; use alternative queuing disciplines such as fq_codel or others
  • Restrict CAP_NET_ADMIN privileges to trusted users and processes to prevent unauthorized manipulation of traffic control settings

Generated by OpenCVE AI on September 20, 2026 at 03:48 UTC.

Tracking

Sign in to view the affected projects.

Advisories
Source ID Title
Debian DLA Debian DLA DLA-4817-1 linux-6.12 security update
Debian DSA Debian DSA DSA-6528-1 linux security update
History

Sun, 20 Sep 2026 04:15:00 +0000

Type Values Removed Values Added
Weaknesses CWE-680

Thu, 17 Sep 2026 16:30:00 +0000

Type Values Removed Values Added
Description In the Linux kernel, the following vulnerability has been resolved: net/sched: hhf: clamp quantum before hhf_change() to avoid overflow hhf_init() sets q->quantum = psched_mtu(qdisc_dev(sch)) with no overflow check. A device with a huge MTU (e.g. dummy with max_mtu == 0 accepting MTU 2147483634) makes weight * quantum overflow the signed deficit in hhf_dequeue(), spinning forever. Clamp q->quantum before hhf_change() so both the opt and !opt paths see a sane quantum. Without this, bare "tc qdisc add ... hhf" succeeds with a clamped quantum but "tc qdisc add ... hhf limit 1000" (any option present) fails with -EINVAL because hhf_change() re-validates the unclamped default (sch_hhf.c:559). 256 matches fq_codel's floor and is a sane minimum for a DRR quantum. Conditions to recreate the bug: a device whose MTU (plus hard_header_len) wraps psched_mtu() into the sign bit (e.g. a dummy device with max_mtu == 0 accepting MTU 2147483634). Requires CAP_NET_ADMIN in a user namespace.
Title net/sched: hhf: clamp quantum before hhf_change() to avoid overflow
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-09-17T16:05:53.562Z

Reserved: 2026-09-11T19:38:34.785Z

Link: CVE-2026-90073

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Received

Published: 2026-09-17T17:16:56.387

Modified: 2026-09-17T17:16:56.387

Link: CVE-2026-90073

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-09-20T04:00:09Z

Weaknesses
  • CWE-680

    Integer Overflow to Buffer Overflow