CVE-2026-68138

What it actually does

This is a Linux kernel race condition in the traffic control scheduler code. Concurrent creation of cls_flower filters using police actions can call qdisc_get_rtab() and qdisc_put_rtab() without the RTNL mutex, allowing unsynchronized mutation of the global qdisc_rtab_list and its non-atomic reference counter. Two simultaneous RTM_NEWTFILTER operations using the same rate table can corrupt the shared rate-table object, producing a use-after-free or double-free of a kmalloc-2k qdisc_rate_table object. The most likely immediate impact is kernel memory corruption and crash, but as with kernel use-after-free conditions, privilege escalation may be possible if an attacker can reliably shape heap state and reclaim the freed object.

Why it matters to the business

Systems running affected Linux kernels may be susceptible to local denial of service through kernel crashes caused by crafted traffic-control configuration activity. The flaw is especially relevant for systems that allow containerized, namespace-based, or delegated networking administration because CAP_NET_ADMIN inside a network namespace may be enough to reach the vulnerable code path even when the global list being corrupted is system-wide. There is no KEV listing and no known ransomware use indicated, but because the issue is newly published and affects kernel memory safety, security teams should prioritize kernel updates on multi-tenant, container-hosting, CI/CD, virtualization, and network-function systems.

How an attack unfolds

An attacker first needs the ability to issue traffic-control netlink operations, typically through CAP_NET_ADMIN or an equivalent path that permits adding flower filters and police actions. They then create concurrent RTM_NEWTFILTER requests, usually by running parallel tc operations or custom netlink code on multiple CPUs. Each request adds a cls_flower filter with a police action using the same configured rate, causing both threads to access the same global qdisc rate-table list. Because one code path may run without the RTNL mutex, the two operations can race while incrementing, decrementing, inserting, unlinking, or freeing the same qdisc_rate_table object. A successful race can leave one CPU using an object that another CPU has freed or can free the same object twice, resulting in kernel memory corruption. In practice, exploitation is expected to be timing-sensitive; the readily achievable outcome is a kernel panic or service outage, while controlled code execution would require additional heap grooming and kernel-specific exploit development.

How to fix it

Upgrade to a Linux kernel version that includes the fix serializing qdisc_rtab_list and its reference count with a dedicated spinlock. If using distribution kernels, apply the vendor security update that backports this patch rather than relying only on upstream version numbers. Where immediate patching is not possible, reduce exposure by restricting CAP_NET_ADMIN, disabling unprivileged user namespaces where operationally feasible, avoiding privileged containers, limiting access to tc/netlink traffic-control configuration, and preventing untrusted workloads from creating cls_flower filters or police actions. On container hosts and multi-tenant Linux systems, treat CAP_NET_ADMIN as a high-risk privilege until patched.

How to confirm the fix worked

Confirm the running kernel includes the vendor fix for the qdisc_rtab_list race in net/sched. Validate by checking the installed kernel package changelog or vendor advisory for the fix referencing serialization of qdisc_get_rtab() and qdisc_put_rtab() with a spinlock. Confirm all hosts have rebooted into the fixed kernel; installing the package alone is insufficient unless live patching explicitly covers this flaw. Exposure can be assessed by reviewing whether untrusted users, containers, orchestration workloads, or services can obtain CAP_NET_ADMIN or create traffic-control flower filters with police actions. In test environments only, kernel sanitizers such as KASAN may confirm the issue by reproducing concurrent tc filter creation, but production validation should rely on package/kernel version verification and privilege review.

Typical attack path

1. Obtain permission to perform Linux traffic-control configuration, such as CAP_NET_ADMIN in a relevant namespace or privileged container context.
2. Identify an interface where cls_flower filters and police actions can be created.
3. Generate two or more concurrent RTM_NEWTFILTER netlink requests that add flower filters with police actions using the same rate-table parameters.
4. Trigger the race in qdisc_get_rtab() and qdisc_put_rtab() while the RTNL mutex is not held.
5. Cause corruption of the global qdisc_rtab_list reference count or list pointers.
6. Achieve a kernel crash, denial of service, or potentially further exploitation if the freed kmalloc-2k object can be predictably reclaimed.

How to detect it

Look for evidence of attempted exploitation in kernel logs, audit logs, shell history, process execution telemetry, and netlink monitoring where available. Relevant kernel artifacts include KASAN reports, slab use-after-free or double-free messages, kernel panics, and stack traces containing qdisc_put_rtab(), qdisc_get_rtab(), tcf_police_init(), fl_change(), tc_new_tfilter(), or rtnetlink_rcv_msg(). Process telemetry may show repeated or parallel invocations of tc adding flower filters with police actions, such as tc filter add ... flower ... action police rate .... Audit logs may show executions of /sbin/tc, /usr/sbin/tc, or custom processes opening NETLINK_ROUTE sockets and issuing RTM_NEWTFILTER messages. On container hosts, correlate crashes or suspicious tc activity with privileged containers, workloads granted CAP_NET_ADMIN, or recent creation of network namespaces. Because no specific public exploit payload is indicated, detection should focus on behavioral patterns: high-rate or concurrent traffic-control filter creation, police action configuration, and subsequent kernel memory-corruption messages or reboots.

• BUG: KASAN: slab-use-after-free in qdisc_put_rtab
• slab-use-after-free in qdisc_put_rtab
• qdisc_put_rtab+
• qdisc_get_rtab+
• tcf_police_init+
• tcf_action_init_1+
• tcf_action_init+
• tcf_exts_validate_ex+
• fl_change+
• tc_new_tfilter+
• rtnetlink_rcv_msg+
• kmalloc-2k of size 2048
• RTM_NEWTFILTER
• TCA_ACT_FLAGS_NO_RTNL
• TCF_PROTO_OPS_DOIT_UNLOCKED
• tc filter add
• flower
• action police
• police rate
• /sbin/tc
• /usr/sbin/tc
• NETLINK_ROUTE

What your security team should do

• Prioritize patching Linux kernels on container hosts, multi-tenant systems, CI runners, network appliances, and systems that grant CAP_NET_ADMIN to workloads.
• Verify that updated systems have rebooted into the fixed kernel or are covered by a live patch that explicitly addresses this qdisc_rtab_list race.
• Audit privileged containers, Kubernetes security contexts, systemd units, and sudo policies for unnecessary CAP_NET_ADMIN access.
• Restrict untrusted users from using tc, rtnetlink traffic-control operations, and privileged network namespace creation.
• Consider disabling unprivileged user namespaces where feasible, especially on shared systems, to reduce paths to namespace-local CAP_NET_ADMIN.
• Monitor kernel logs for KASAN, slab-use-after-free, double-free, or panic traces involving qdisc_put_rtab, qdisc_get_rtab, tcf_police_init, cls_flower, fl_change, or tc_new_tfilter.
• Add SIEM detections for bursts of traffic-control filter additions, especially repeated flower filters with police actions created concurrently.
• Treat unexplained kernel crashes with the relevant stack traces as potential exploitation attempts and preserve logs, kernel crash dumps, and audit records.