CVE-2026-72390: net/sched: sch_teql: Introduce slaves_lock to avoid race condition and UAF

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

net/sched: schteql: Introduce slaveslock to avoid race condition and UAF

The teql master->slaves singly linked list is not protected against multiple writes. It can be mod'ed concurently from teqlmasterxmit(), teqldequeue(), teqlinit() and teqldestroy() without holding any list lock or RCU protection.

zdi-disclosures@trendmicro.com has demonstrated that the qdisc is freed after an RCU grace period, but teqlmasterxmit() running on another CPU can still hold a stale pointer into the list, resulting in a slab-use-after-free:

BUG: KASAN: slab-use-after-free in teqlmasterxmit+0xf0f/0x16b0 Read of size 8 at addr ffff888013fb0440 by task poc/332 Freed 512-byte region [ffff888013fb0400, ffff888013fb0600) (kmalloc-512)

The fix? Add a per-master slaveslock spinlock that serializes all mutations of master->slaves and the NEXTSLAVE() links in teqldestroy() and teqlqdiscinit(). teqlmasterxmit() also takes the same slaveslock around those updates. Annotate master->slaves and the per-slave ->next pointer with rcu and use the appropriate RCU accessors everywhere they are touched: rcuassignpointer() on the writer side (under slaveslock), rcudereferenceprotected() for the writer-side loads (also under slaveslock), rcudereferencebh() for the loads in teqlmasterxmit() and rtnldereference() for the loads in teqlmasteropen()/teqlmastermtu(), which run under RTNL. Pair this with rcureadlockbh()/rcureadunlockbh() around the list traversal in teqlmasterxmit(), so that readers either observe a fully linked list or are deferred until the in-flight mutation completes. The two early-return paths in teqlmasterxmit() are updated to release the RCU-bh read-side critical section before returning, since leaving it held would disable BH on that CPU for good.