CVE-2026-90073: net/sched: hhf: clamp quantum before hhf_change() to avoid overflow

Published Sep 17, 2026
·
Updated

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

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

hhfinit() sets q->quantum = pschedmtu(qdiscdev(sch)) with no overflow check. A device with a huge MTU (e.g. dummy with maxmtu == 0 accepting MTU 2147483634) makes weight quantum overflow the signed deficit in hhfdequeue(), spinning forever.

Clamp q->quantum before hhfchange() 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 hhfchange() re-validates the unclamped default (schhhf.c:559). 256 matches fqcodel's floor and is a sane minimum for a DRR quantum.

Conditions to recreate the bug: a device whose MTU (plus hardheaderlen) wraps pschedmtu() into the sign bit (e.g. a dummy device with maxmtu == 0 accepting MTU 2147483634). Requires CAPNETADMIN in a user namespace.

Affected Software

1 affected component
Linux Linux kernel

Event History

Sep 17, 2026
CVE Published
via MITRE·04:05 PM
Data Sourced
via MITRE·04:05 PM
Description

Frequently Asked Questions

1

Who can realistically trigger this issue?

An attacker needs CAP_NET_ADMIN in a user namespace and access to a network device that accepts an extremely large MTU. The example given is a dummy device with max_mtu set to 0 that accepts an MTU of 2147483634.

2

What conditions cause the scheduler to become stuck?

The device MTU plus hard_header_len must cause psched_mtu() to wrap into the sign bit. When HHF processes traffic with the resulting quantum, weight multiplied by quantum can overflow its signed deficit value in hhf_dequeue(), causing it to spin indefinitely.

3

Is HHF affected when added with its default settings?

Yes. Adding an HHF qdisc without options succeeds with a clamped quantum, while adding it with any option, such as "limit 1000", can fail with -EINVAL because the previously unclamped default is revalidated.

4

What does the fix change?

The fix clamps the HHF quantum before hhf_change() runs, ensuring both the default and option-specified configuration paths use a sane quantum. It uses 256 as the minimum quantum floor.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203