CVE-2026-74284

CVE CVE-2026-74284EUVD EUVD-2026-59431Published 2026-08-15T05:57:53.000ZLast changed 2026-08-17T05:16:29.000Z

What the advisory describes

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.

Source: EUVD (ENISA), in the words of the advisory.

Products the advisory names

These come from the advisory itself, not from any check we performed.

• Linux — Linux c1175c4ad01dbc9c979d099861fa90a754f72059; patch: 0; patch: 7.1.5; 51eb3b65544c9efd6a1026889ee5fb5aa62da3bb <3a49bbae676fef1ffe548971e6229ae2adeb9d10; 51eb3b65544c9efd6a1026889ee5fb5aa62da3bb <90b662ea25f5e83bb3b8ccec5b93ced810b92fb8; 6.15; 6.1.138 <6.1.178; 6.12.28 <6.12.97; patch: 6.18.40; d06476714d2819b550e0cc39222347e2c8941c9d <9221a594c72a1446137926d4c2aa04e345f798dc; a5efc95a33bd4fcb879250852828cc58c7862970 <fc973ecd1a079b9a87c360478542f3a56dea085b; patch: 6.6.145; patch: 5.10.261; patch: 5.15.212; patch: 7.2; 5.10.241 <5.10.261; patch: 6.12.97; 51eb3b65544c9efd6a1026889ee5fb5aa62da3bb <66dbb13eeb2fc339f8f548a9076be4c1a94857b0; 6.6.90 <6.6.145; patch: 6.1.178; 9030a91235ae4845ec71902c3e0cecfc9ed1f2df <b2a017bfcf565721918ec7355a373911d2f2a227; 5.15.190 <5.15.212; 72c61ffbeeb8c50f6d4d70c65d3283aa1bac57a7 <a425c82ff06cda5165e0de3de8c2a445ec1f863e; 6.14.6 <6.15; 5.4.297 <5.5; 9a5fd5c2f4d4afdd5e405083ee53e0789ce76956; 0475c85426b18eccdcb7f9fb58d8f8e9c6c58c87 <15720cd8fa3fc625146128f89a8e11b0449a20a7

The versions shown are the advisory's own. Patchlage compares no version numbers and derives no judgement from them — which version is installed is something a person has to look up.

Carried in the product catalogue

An estate covering these products can be recorded in Patchlage. An advisory about them appears in the next morning's situation report.

• Linux — Linux

Patchlage reports hits and suspected hits. About everything else this system says nothing — neither this page nor the situation report ever claims that an estate is safe.