CVE-2026-68138: net/sched: serialize qdisc_rtab_list against concurrent get/put

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

net/sched: serialize qdiscrtablist against concurrent get/put

qdiscgetrtab() and qdiscputrtab() mutate the process-global singly linked list qdiscrtablist and a plain non-atomic 'int refcnt' with no lock. This was only safe because every caller historically held the RTNL mutex, which serialized all rate-table lookups, inserts and frees.

That invariant no longer holds. clsflower sets TCFPROTOOPSDOITUNLOCKED, so tcnewtfilter() keeps rtnlheld == false for it and sets TCAACTFLAGSNORTNL. That flag propagates through tcfextsvalidateex() -> tcfactioninit() -> tcfactioninit1() -> tcfpoliceinit(), which calls qdiscgetrtab()/qdiscputrtab() with the RTNL mutex NOT held. Two RTMNEWTFILTER requests on different CPUs, each adding a flower filter with a police action carrying the same rate, then race on qdiscrtablist and on the non-atomic refcnt, leading to a use-after-free / double-free of the kmalloc-2k struct qdiscratetable. qdiscrtablist is a single global (not per-netns), so the corrupted object is shared system-wide.

BUG: KASAN: slab-use-after-free in qdiscputrtab+0x12f/0x160 qdiscputrtab+0x12f/0x160 tcfpoliceinit+0xda9/0x1590 tcfactioninit1+0x460/0x6b0 tcfactioninit+0x439/0xa40 tcfextsvalidateex+0x42d/0x550 flchange+0xddd/0x7da0 tcnewtfilter+0xaa7/0x2420 rtnetlinkrcvmsg+0x95e/0xe90 which belongs to the cache kmalloc-2k of size 2048

Protect qdiscrtablist and the refcount with a dedicated spinlock. The (sleeping, GFPKERNEL) allocation in qdiscgetrtab() is performed before taking the lock; if a concurrent inserter added an identical table in the meantime the freshly allocated one is freed under the lock, so no duplicate is leaked. qdiscputrtab() now decrements the refcount and unlinks under the same lock.