net_sched: 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->cl_nactive field to determine whether
it is the first insertion or not [2], but this field is only
incremented by init_vf [3].
By using HFSC_RSC (which uses init_ed) [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
hfsc_dequeue 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 hfsc_enqueue whether the class is already in the eltree
whenever the HFSC_RSC 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/sch_hfsc.c#L1572
[3] https://elixir.bootlin.com/linux/v6.15-rc5/source/net/sched/sch_hfsc.c#L677
[4] https://elixir.bootlin.com/linux/v6.15-rc5/source/net/sched/sch_hfsc.c#L1574
[5] https://lore.kernel.org/netdev/8DuRWwfqjoRDLDmBMlIfbrsZg9Gx50DHJc1ilxsEBNe2D6NMoigR_eIRIG0LOjMc3r10nUUZtArXx4oZBIdUfZQrwjcQhdinnMis_0G7VEk=@willsroot.io/T/#u
Analysis and contextual insights are available on OpenCVE Cloud.
No vendor fix or workaround currently provided.
Additional remediation guidance may be available on OpenCVE Cloud.
Tracking
Sign in to view the affected projects.
| Source | ID | Title |
|---|---|---|
Debian DLA |
DLA-4327-1 | linux security update |
Debian DLA |
DLA-4328-1 | linux-6.1 security update |
Debian DSA |
DSA-5973-1 | linux security update |
EUVD |
EUVD-2025-17306 | In the Linux kernel, the following vulnerability has been resolved: net_sched: 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->cl_nactive field to determine whether it is the first insertion or not [2], but this field is only incremented by init_vf [3]. By using HFSC_RSC (which uses init_ed) [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 hfsc_dequeue 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 hfsc_enqueue whether the class is already in the eltree whenever the HFSC_RSC 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/sch_hfsc.c#L1572 [3] https://elixir.bootlin.com/linux/v6.15-rc5/source/net/sched/sch_hfsc.c#L677 [4] https://elixir.bootlin.com/linux/v6.15-rc5/source/net/sched/sch_hfsc.c#L1574 [5] https://lore.kernel.org/netdev/8DuRWwfqjoRDLDmBMlIfbrsZg9Gx50DHJc1ilxsEBNe2D6NMoigR_eIRIG0LOjMc3r10nUUZtArXx4oZBIdUfZQrwjcQhdinnMis_0G7VEk=@willsroot.io/T/#u |
Ubuntu USN |
USN-7608-1 | Linux kernel vulnerabilities |
Ubuntu USN |
USN-7608-2 | Linux kernel (FIPS) vulnerabilities |
Ubuntu USN |
USN-7608-3 | Linux kernel (Real-time) vulnerabilities |
Ubuntu USN |
USN-7608-4 | Linux kernel vulnerabilities |
Ubuntu USN |
USN-7608-5 | Linux kernel vulnerabilities |
Ubuntu USN |
USN-7608-6 | Linux kernel (Xilinx ZynqMP) vulnerabilities |
Ubuntu USN |
USN-7608-7 | Linux kernel (Azure) vulnerabilities |
Ubuntu USN |
USN-7609-1 | Linux kernel vulnerabilities |
Ubuntu USN |
USN-7609-2 | Linux kernel (Real-time) vulnerabilities |
Ubuntu USN |
USN-7609-3 | Linux kernel (IBM) vulnerabilities |
Ubuntu USN |
USN-7609-4 | Linux kernel (Azure) vulnerabilities |
Ubuntu USN |
USN-7609-5 | Linux kernel (Azure) vulnerabilities |
Ubuntu USN |
USN-7610-1 | Linux kernel vulnerabilities |
Ubuntu USN |
USN-7610-2 | Linux kernel vulnerabilities |
Ubuntu USN |
USN-7610-3 | Linux kernel (Low Latency) vulnerabilities |
Ubuntu USN |
USN-7611-1 | Linux kernel vulnerabilities |
Ubuntu USN |
USN-7611-2 | Linux kernel (Azure) vulnerabilities |
Ubuntu USN |
USN-7611-3 | Linux kernel (AWS) vulnerabilities |
Ubuntu USN |
USN-7611-4 | Linux kernel (Oracle) vulnerabilities |
Ubuntu USN |
USN-7618-1 | Linux kernel (OEM) vulnerabilities |
Ubuntu USN |
USN-7628-1 | Linux kernel (Azure) vulnerabilities |
Ubuntu USN |
USN-7653-1 | Linux kernel (HWE) vulnerabilities |
Ubuntu USN |
USN-7655-1 | Linux kernel (Intel IoTG) vulnerabilities |
Ubuntu USN |
USN-7665-2 | Linux kernel (AWS) vulnerabilities |
Ubuntu USN |
USN-7671-1 | Linux kernel vulnerabilities |
Ubuntu USN |
USN-7671-2 | Linux kernel vulnerabilities |
Ubuntu USN |
USN-7671-3 | Linux kernel (IoT) vulnerabilities |
Ubuntu USN |
USN-7686-1 | Linux kernel (Raspberry Pi) vulnerabilities |
Ubuntu USN |
USN-7712-1 | Linux kernel (Azure FIPS) vulnerabilities |
Ubuntu USN |
USN-7712-2 | Linux kernel (Azure) vulnerabilities |
Wed, 17 Dec 2025 19:30:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| First Time appeared |
Debian
Debian debian Linux |
|
| Weaknesses | CWE-835 | |
| CPEs | cpe:2.3:o:debian:debian_linux:11.0:*:*:*:*:*:*:* cpe:2.3:o:debian:debian_linux:12.0:*:*:*:*:*:*:* cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* cpe:2.3:o:linux:linux_kernel:5.0:-:*:*:*:*:*:* cpe:2.3:o:linux:linux_kernel:5.0:rc3:*:*:*:*:*:* cpe:2.3:o:linux:linux_kernel:5.0:rc4:*:*:*:*:*:* cpe:2.3:o:linux:linux_kernel:5.0:rc5:*:*:*:*:*:* cpe:2.3:o:linux:linux_kernel:5.0:rc6:*:*:*:*:*:* cpe:2.3:o:linux:linux_kernel:5.0:rc7:*:*:*:*:*:* cpe:2.3:o:linux:linux_kernel:5.0:rc8:*:*:*:*:*:* |
|
| Vendors & Products |
Debian
Debian debian Linux |
|
| Metrics |
cvssV3_1
|
cvssV3_1
|
Mon, 03 Nov 2025 18:30:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| References |
|
Sun, 13 Jul 2025 19:30:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| References |
|
Fri, 27 Jun 2025 14:45:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| Metrics |
cvssV3_1
|
cvssV3_1
|
Tue, 10 Jun 2025 19:00:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| Metrics |
cvssV3_1
|
cvssV3_1
|
Mon, 09 Jun 2025 14:30:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| References |
|
Sat, 07 Jun 2025 02:45:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| References |
| |
| Metrics |
threat_severity
|
cvssV3_1
|
Fri, 06 Jun 2025 14:00:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| Description | In the Linux kernel, the following vulnerability has been resolved: net_sched: 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->cl_nactive field to determine whether it is the first insertion or not [2], but this field is only incremented by init_vf [3]. By using HFSC_RSC (which uses init_ed) [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 hfsc_dequeue 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 hfsc_enqueue whether the class is already in the eltree whenever the HFSC_RSC 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/sch_hfsc.c#L1572 [3] https://elixir.bootlin.com/linux/v6.15-rc5/source/net/sched/sch_hfsc.c#L677 [4] https://elixir.bootlin.com/linux/v6.15-rc5/source/net/sched/sch_hfsc.c#L1574 [5] https://lore.kernel.org/netdev/8DuRWwfqjoRDLDmBMlIfbrsZg9Gx50DHJc1ilxsEBNe2D6NMoigR_eIRIG0LOjMc3r10nUUZtArXx4oZBIdUfZQrwjcQhdinnMis_0G7VEk=@willsroot.io/T/#u | |
| Title | net_sched: hfsc: Address reentrant enqueue adding class to eltree twice | |
| References |
|
|
Status: PUBLISHED
Assigner: Linux
Published:
Updated: 2026-05-11T21:19:23.669Z
Reserved: 2025-04-16T04:51:23.976Z
Link: CVE-2025-38001
No data.
Status : Modified
Published: 2025-06-06T14:15:22.183
Modified: 2026-03-07T12:15:53.730
Link: CVE-2025-38001
OpenCVE Enrichment
Updated: 2025-06-24T09:44:12Z
Debian DLA
Debian DSA
EUVD
Ubuntu USN