CVE-2026-74284
net/sched: sch_hfsc: Don't make class passive twice
Published Aug 15, 2026
CVSS 3.1 · 5.5 Medium
EPSS < 1%
KEV · Not listed
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.
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.
Affected Products
-
CVE record
-
NVD configurations
No data
-
Red Hat packages
No data
-
OpenCVE enrichment
Default status is the baseline for the product, each version can override it (e.g. patched versions marked unaffected).
| Vendor | Product | Default status | Versions | ||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Linux | Linux | unaffected |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Linux | Linux | affected |
|
No data.
No data.
| Vendor | Product | Versions | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Linux | Linux Kernel |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Linux | Linux Kernel |
|
Remediation
Tracking
Advisories
| Source | ID | Title |
|---|---|---|
 Ubuntu USN |
USN-8876-1 | Linux kernel (Azure CVM) vulnerabilities |
| Ubuntu USN |
USN-8875-1 | Linux kernel vulnerabilities |
| Ubuntu USN |
USN-8877-1 | Linux kernel (GCP) vulnerabilities |
| Ubuntu USN |
USN-8878-1 | Linux kernel (GCP) vulnerabilities |
| Ubuntu USN |
USN-8879-1 | Linux kernel (Oracle) vulnerabilities |
| Ubuntu USN |
USN-8887-1 | Linux kernel vulnerabilities |
| Ubuntu USN |
USN-8888-1 | Linux kernel (Azure) vulnerabilities |
| Ubuntu USN |
USN-8889-1 | Linux kernel (OEM) vulnerabilities |
| Ubuntu USN |
USN-8887-2 | Linux kernel (AWS) vulnerabilities |
| Ubuntu USN |
USN-8888-2 | Linux kernel (Azure) vulnerabilities |
| Ubuntu USN |
USN-8875-2 | Linux kernel (NVIDIA) vulnerabilities |
| Ubuntu USN |
USN-8887-3 | Linux kernel vulnerabilities |
| Ubuntu USN |
USN-8917-1 | Linux kernel vulnerabilities |
| Ubuntu USN |
USN-8918-1 | Linux kernel (Azure) vulnerabilities |
| Ubuntu USN |
USN-9003-1 | Linux kernel (NVIDIA) vulnerabilities |
| Ubuntu USN |
USN-9024-1 | Linux kernel vulnerabilities |
| Ubuntu USN |
USN-9025-1 | Linux kernel vulnerabilities |
| Ubuntu USN |
USN-9026-1 | Linux kernel (Azure) vulnerabilities |
| Ubuntu USN |
USN-9029-1 | Linux kernel (Raspberry Pi) vulnerabilities |
| Ubuntu USN |
USN-9040-1 | Linux kernel (Low Latency NVIDIA) vulnerabilities |
| Ubuntu USN |
USN-9043-1 | Linux kernel (NVIDIA) vulnerabilities |
| Ubuntu USN |
USN-9066-1 | Linux kernel (HWE) vulnerabilities |
| Ubuntu USN |
USN-9091-1 | Linux kernel (NVIDIA Tegra) vulnerabilities |
Metrics
No CVSS v4.0
Attack Vector Local
Attack Complexity Low
Privileges Required Low
Scope Unchanged
Confidentiality Impact None
Integrity Impact None
Availability Impact High
User Interaction None
No CVSS v3.0
No CVSS v2
This CVE is not in the KEV list.
Exploit prediction score: < 1% (0.216% probability within 30 days)
Exploitation none
Automatable no
Technical Impact partial
References
History
Nov 7, 2026 7:30 AM
Scoring metrics updated
View changes
| Type | Values Removed | Values Added |
|---|---|---|
| Metrics |
ssvc
|
Aug 22, 2026 2:00 AM
Weaknesses updated
View changes
| Type | Values Removed | Values Added |
|---|---|---|
| Weaknesses | CWE-682 |
Aug 21, 2026 12:15 AM
Weaknesses updated. Added references. Scoring metrics updated
View changes
| Type | Values Removed | Values Added |
|---|---|---|
| Weaknesses | CWE-821 | |
| References |
| |
| Metrics |
threat_severity
|
cvssV3_1
|
Aug 15, 2026 6:30 PM
Weaknesses updated
View changes
| Type | Values Removed | Values Added |
|---|---|---|
| Weaknesses | CWE-682 |
Aug 15, 2026 6:15 AM
Description updated. Title updated. First appearance in the feed. Affected versions updated. Affected vendors updated. Added references
View changes
| Type | Values Removed | Values Added |
|---|---|---|
| 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. | |
| Title | net/sched: sch_hfsc: Don't make class passive twice | |
| First Time appeared |
Linux
Linux linux Kernel |
|
| CPEs | cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* | |
| Vendors & Products |
Linux
Linux linux Kernel |
|
| References |
|
|
Subscriptions
Weaknesses
