CVE-2026-74284

net/sched: sch_hfsc: Don't make class passive twice

State
Published
Severity
Not scored
Published
Aug 15, 2026
Updated
Aug 17, 2026
Reserved
Aug 15, 2026

Read the record on cve.org

Description

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

net/sched: sch_hfsc: Don't make class passive twice

update_vf() is called from two places for the same class during a single dequeue when the class's child qdisc (e.g. codel/fq_codel) drops its last packets while dequeuing:

1. The child calls qdisc_tree_reduce_backlog(), which, now that the child is empty, invokes hfsc_qlen_notify() -> update_vf(cl, 0, 0) and turns the class passive (cl_nactive is decremented up the hierarchy).

2. hfsc_dequeue() then calls update_vf(cl, qdisc_pkt_len(skb), cur_time) to charge the dequeued bytes.

On the second call the class is already passive, but its child qdisc is still empty, so update_vf() arms go_passive again:

if (cl->qdisc->q.qlen == 0 && cl->cl_flags & HFSC_FSC) go_passive = 1;

The leaf is then skipped by the cl_nactive == 0 check inside the loop, which does not clear go_passive, so the stale go_passive propagates to the parent and decrements its cl_nactive a second time. A parent that still has other active children is driven to cl_nactive == 0 and removed from the vttree, even though those siblings are still backlogged. They are never dequeued again and the qdisc stalls.

Fix this by only arming go_passive when the class is actually active, so an already-passive class no longer triggers a second passive transition. The byte accounting (cl->cl_total += len) still runs for every ancestor, so dequeued bytes continue to be counted exactly once.

Scores

The record has no CVSS score.

Weaknesses

The record names no weakness.

Affected Products

ProductVersions
LinuxLinux
  • 72c61ffbeeb8c50f6d4d70c65d3283aa1bac57a7 to before a425c82ff06cda5165e0de3de8c2a445ec1f863eAffected
  • a5efc95a33bd4fcb879250852828cc58c7862970 to before fc973ecd1a079b9a87c360478542f3a56dea085bAffected
  • 0475c85426b18eccdcb7f9fb58d8f8e9c6c58c87 to before 15720cd8fa3fc625146128f89a8e11b0449a20a7Affected
  • 9030a91235ae4845ec71902c3e0cecfc9ed1f2df to before b2a017bfcf565721918ec7355a373911d2f2a227Affected
  • d06476714d2819b550e0cc39222347e2c8941c9d to before 9221a594c72a1446137926d4c2aa04e345f798dcAffected
  • 51eb3b65544c9efd6a1026889ee5fb5aa62da3bb to before 66dbb13eeb2fc339f8f548a9076be4c1a94857b0Affected
  • 51eb3b65544c9efd6a1026889ee5fb5aa62da3bb to before 3a49bbae676fef1ffe548971e6229ae2adeb9d10Affected
  • 51eb3b65544c9efd6a1026889ee5fb5aa62da3bb to before 90b662ea25f5e83bb3b8ccec5b93ced810b92fb8Affected
  • 9a5fd5c2f4d4afdd5e405083ee53e0789ce76956Affected
  • c1175c4ad01dbc9c979d099861fa90a754f72059Affected
  • 5.10.241 to before 5.10.261Affected
  • 5.15.190 to before 5.15.212Affected
  • 6.1.138 to before 6.1.178Affected
  • 6.6.90 to before 6.6.145Affected
  • 6.12.28 to before 6.12.97Affected
  • 5.4.297 to before 5.5Affected
  • 6.14.6 to before 6.15Affected
LinuxLinux
  • 6.15Affected
  • before 6.15Not affected
  • 5.10.261 through 5.10.*Not affected
  • 5.15.212 through 5.15.*Not affected
  • 6.1.178 through 6.1.*Not affected
  • 6.6.145 through 6.6.*Not affected
  • 6.12.97 through 6.12.*Not affected
  • 6.18.40 through 6.18.*Not affected
  • 7.1.5 through 7.1.*Not affected
  • 7.2 and laterNot affected

References

Every record here comes from the CVE Program’s CVE List. © 1999–2026 The MITRE Corporation. CVE is a registered trademark of The MITRE Corporation. The records are reproduced under the CVE Program terms of use.