CVE-2026-68138
PoC massUse-after-free race in Linux kernel traffic-control (net/sched) qdisc rate tables
The Linux kernel's traffic-control subsystem keeps qdisc rate tables on a single process-global list (qdisc_rtab_list) with a non-atomic refcount, historically serialized only by the RTNL mutex; the flower classifier (cls_flower) now runs unlocked (TCF_PROTO_OPS_DOIT_UNLOCKED, TCA_ACT_FLAGS_NO_RTNL), so police-action initialization calls qdisc_get_rtab()/qdisc_put_rtab() without that lock. Two concurrent RTM_NEWTFILTER netlink requests on different CPUs, each adding a flower filter with a police action carrying the same rate, race on the list and refcount, causing a use-after-free or double-free of the 2 KB (kmalloc-2k) qdisc_rate_table object. Because the list is global rather than per-network-namespace, the corrupted object is shared system-wide, and a local low-privilege attacker able to add traffic filters (e.g., with CAP_NET_ADMIN in a namespace) could gain kernel memory corruption with high confidentiality, integrity and availability impact (CVSS 7.8). Any Linux kernel where the flower classifier's unlocked path propagates NO_RTNL to tcf_police_init is affected; the source data does not specify exact version ranges. No in-the-wild exploitation is reported; EPSS is 0.3% and the flaw is not in CISA KEV, but one public proof-of-concept is available on GitHub.
What to do: Apply kernel updates that include the fix serializing qdisc_rtab_list and its refcount with a dedicated spinlock (check your distro/vendor's stable backports; no fixed version number is given in this data). As interim mitigation, restrict CAP_NET_ADMIN in untrusted containers or network namespaces and audit whether tc flower filters with police actions are in use (e.g., via 'tc filter show'); exploitation requires local privilege, so internet-facing exposure is limited to multi-tenant hosts.
| Linux kernel (net/sched traffic control; cls_flower with police action) | — |
Order-of-magnitude estimate by the model from install counts, market share and public scan data it knows; verify before quoting.
In the Linux kernel, the following vulnerability has been resolved: net/sched: serialize qdisc_rtab_list against concurrent get/put qdisc_get_rtab() and qdisc_put_rtab() mutate the process-global singly linked list qdisc_rtab_list 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. cls_flower sets TCF_PROTO_OPS_DOIT_UNLOCKED, so tc_new_tfilter() keeps rtnl_held == false for it and sets TCA_ACT_FLAGS_NO_RTNL. That flag propagates through tcf_exts_validate_ex() -> tcf_action_init() -> tcf_action_init_1() -> tcf_police_init(), which calls qdisc_get_rtab()/qdisc_put_rtab() with the RTNL mutex NOT held. Two RTM_NEWTFILTER requests on different CPUs, each adding a flower filter with a police action carrying the same rate, then race on qdisc_rtab_list and on the non-atomic refcnt, leading to a use-after-free / double-free of the kmalloc-2k struct qdisc_rate_table. qdisc_rtab_list is a single global (not per-netns), so the corrupted object is shared system-wide. BUG: KASAN: slab-use-after-free in qdisc_put_rtab+0x12f/0x160 qdisc_put_rtab+0x12f/0x160 tcf_police_init+0xda9/0x1590 tcf_action_init_1+0x460/0x6b0 tcf_action_init+0x439/0xa40 tcf_exts_validate_ex+0x42d/0x550 fl_change+0xddd/0x7da0 tc_new_tfilter+0xaa7/0x2420 rtnetlink_rcv_msg+0x95e/0xe90 which belongs to the cache kmalloc-2k of size 2048 Protect qdisc_rtab_list and the refcount with a dedicated spinlock. The (sleeping, GFP_KERNEL) allocation in qdisc_get_rtab() 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. qdisc_put_rtab() now decrements the refcount and unlinks under the same lock.
- Vector
- CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
In the news0 stories
No ingested article mentions this CVE yet.