CVE-2025-38001: net_sched: hfsc: Address reentrant enqueue adding class to eltree twice
In the Linux kernel, the following vulnerability has been resolved:
netsched: hfsc: Address reentrant enqueue adding class to eltree twice
Savino says: "We are writing to report that this recent patch (141d34391abbb315d68556b7c67ad97885407547) [1] can be bypassed, and a UAF can still occur when HFSC is utilized with NETEM.
The patch only checks the cl->clnactive field to determine whether it is the first insertion or not [2], but this field is only incremented by initvf [3].
By using HFSCRSC (which uses inited) [4], it is possible to bypass the check and insert the class twice in the eltree. Under normal conditions, this would lead to an infinite loop in hfscdequeue for the reasons we already explained in this report [5].
However, if TBF is added as root qdisc and it is configured with a very low rate, it can be utilized to prevent packets from being dequeued. This behavior can be exploited to perform subsequent insertions in the HFSC eltree and cause a UAF."
To fix both the UAF and the infinite loop, with netem as an hfsc child, check explicitly in hfscenqueue whether the class is already in the eltree whenever the HFSCRSC flag is set.
[1] <a href="https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=141d34391abbb315d68556b7c67ad97885407547">https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=141d34391abbb315d68556b7c67ad97885407547</a> [2] <a href="https://elixir.bootlin.com/linux/v6.15-rc5/source/net/sched/schhfsc.c#L1572">https://elixir.bootlin.com/linux/v6.15-rc5/source/net/sched/schhfsc.c#L1572</a> [3] <a href="https://elixir.bootlin.com/linux/v6.15-rc5/source/net/sched/schhfsc.c#L677">https://elixir.bootlin.com/linux/v6.15-rc5/source/net/sched/schhfsc.c#L677</a> [4] <a href="https://elixir.bootlin.com/linux/v6.15-rc5/source/net/sched/schhfsc.c#L1574">https://elixir.bootlin.com/linux/v6.15-rc5/source/net/sched/schhfsc.c#L1574</a> [5] <a href="https://lore.kernel.org/netdev/8DuRWwfqjoRDLDmBMlIfbrsZg9Gx50DHJc1ilxsEBNe2D6NMoigReIRIG0LOjMc3r10nUUZtArXx4oZBIdUfZQrwjcQhdinnMis0G7VEk=@willsroot.io/T/#u">https://lore.kernel.org/netdev/8DuRWwfqjoRDLDmBMlIfbrsZg9Gx50DHJc1ilxsEBNe2D6NMoigReIRIG0LOjMc3r10nUUZtArXx4oZBIdUfZQrwjcQhdinnMis0G7VEk=@willsroot.io/T/#u</a>
Other sources
In the Linux kernel, the following vulnerability has been resolved:
netsched: hfsc: Address reentrant enqueue adding class to eltree twice
Savino says: "We are writing to report that this recent patch (141d34391abbb315d68556b7c67ad97885407547) [1] can be bypassed, and a UAF can still occur when HFSC is utilized with NETEM.
The patch only checks the cl->clnactive field to determine whether it is the first insertion or not [2], but this field is only incremented by initvf [3].
By using HFSCRSC (which uses inited) [4], it is possible to bypass the check and insert the class twice in the eltree. Under normal conditions, this would lead to an infinite loop in hfscdequeue for the reasons we already explained in this report [5].
However, if TBF is added as root qdisc and it is configured with a very low rate, it can be utilized to prevent packets from being dequeued. This behavior can be exploited to perform subsequent insertions in the HFSC eltree and cause a UAF."
To fix both the UAF and the infinite loop, with netem as an hfsc child, check explicitly in hfscenqueue whether the class is already in the eltree whenever the HFSCRSC flag is set.
[1] https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=141d34391abbb315d68556b7c67ad97885407547 [2] https://elixir.bootlin.com/linux/v6.15-rc5/source/net/sched/schhfsc.c#L1572 [3] https://elixir.bootlin.com/linux/v6.15-rc5/source/net/sched/schhfsc.c#L677 [4] https://elixir.bootlin.com/linux/v6.15-rc5/source/net/sched/schhfsc.c#L1574 [5] https://lore.kernel.org/netdev/8DuRWwfqjoRDLDmBMlIfbrsZg9Gx50DHJc1ilxsEBNe2D6NMoigReIRIG0LOjMc3r10nUUZtArXx4oZBIdUfZQrwjcQhdinnMis0G7VEk=@willsroot.io/T/#u
— NVD
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Patch 141d34391abbb315d68556b7c67ad97885407547 - Configuration
Apply the upstream patch 141d34391abbb315d68556b7c67ad97885407547 so that, when netem is used as an hfsc child, the kernel does not reentrantly enqueue a class into the eltree twice (fixes both the UAF and infinite loop).
Linux kernel netem (netem) as HFSC child qdisc TBF as root qdisc and HFSC netem-child configuration = Configure TBF as the root qdisc and netem as an hfsc child as described by the upstream fix; ensure HFSC enqueue/dequeue logic includes explicit eltree membership checks to prevent double-insert UAF/infinite-loop
Event History
Peer vulnerabilities
Found alongside the following vulnerabilities.
Frequently Asked Questions
What is the severity of CVE-2025-38001?
The severity of CVE-2025-38001 is currently under analysis as it was recently patched in the Linux kernel.
How do I fix CVE-2025-38001?
To fix CVE-2025-38001, you should update your Linux kernel to the latest version where the vulnerability has been resolved.
Which versions of the Linux kernel are affected by CVE-2025-38001?
CVE-2025-38001 affects specific versions of the Linux kernel prior to the application of the relevant patch.
What type of vulnerability is CVE-2025-38001?
CVE-2025-38001 is a vulnerability in the net_sched component of the Linux kernel related to address reentrancy.
Is there a known exploit for CVE-2025-38001?
Currently, there are no public details indicating the existence of an exploit for CVE-2025-38001.