CVE-2026-53264

What it actually does

This is a Linux kernel use-after-free race in the traffic control action lifecycle under net/sched. Concurrent creation and deletion of traffic control filters can allow one execution path to look up a tc_action object while another removes it from the IDR and immediately frees it. A stale pointer can then be used during reference count handling, creating a kernel memory safety condition. The upstream fix defers freeing through RCU so readers that are still inside an RCU read-side critical section cannot access memory that has already been returned to the allocator. Practical impact is most likely local kernel denial of service, with potential for local privilege escalation if an attacker can reliably win the race and shape kernel heap reuse.

Why it matters to the business

Systems running affected Linux kernels may be vulnerable to local crashes or possible privilege escalation by users, workloads, or containers that can manipulate Linux traffic control objects. The issue is not currently listed in CISA KEV, has low EPSS, and has no reported public exploit maturity in the provided data, so broad internet-scale exploitation is unlikely; however, exposure is more important on multi-user hosts, container platforms, CI runners, appliances, and systems that grant CAP_NET_ADMIN or allow unprivileged network namespaces.

How an attack unfolds

An attacker first needs the ability to issue traffic control netlink operations, typically through CAP_NET_ADMIN in a network namespace or a privileged/containerized context that can create and delete qdisc filters and actions. The attacker prepares traffic control actions, then repeatedly races NEWTFILTER and DELFILTER operations across threads or processes. In the vulnerable code path, one CPU can retrieve a tc_action pointer from the IDR while another CPU decrements the final reference, removes the action from the IDR, and frees the object immediately. The first CPU may then operate on the freed object, producing a use-after-free. A simple exploit may cause a kernel oops or panic; a more advanced exploit would attempt heap grooming so the freed action memory is reallocated with attacker-influenced data, potentially converting the race into kernel control-flow or data corruption for privilege escalation. The patched behavior uses RCU-deferred freeing so stale readers complete before the memory is released.

How to fix it

Upgrade to a Linux kernel build that includes the upstream fix for net/sched act_api RCU-deferred freeing of tc_action objects. Because no product-specific fixed versions were provided, use the fixed kernel versions from the relevant Linux distribution, appliance vendor, cloud image, or embedded platform advisory. Reboot into the updated kernel and remove or decommission vulnerable kernels where possible. If immediate patching is not possible, reduce exposure by limiting CAP_NET_ADMIN, disabling unprivileged user namespaces where operationally feasible, restricting container privileges, preventing untrusted users from running tc/iproute2 network configuration commands, and applying least privilege to workloads that can create network namespaces or manipulate traffic control.

How to confirm the fix worked

Confirm the running kernel, not only the installed package, has been updated by checking uname -r and matching it against the vendor advisory for this issue. Verify that the kernel changelog or source contains the net/sched act_api fix that defers tc_action freeing with RCU/kfree_rcu/call_rcu. Review container and host hardening posture to ensure untrusted workloads do not receive CAP_NET_ADMIN unless required. Where feasible in a non-production test environment, run kernel regression tests or traffic-control stress tests that repeatedly create and delete filters/actions and confirm there are no kernel oops, KASAN use-after-free reports, lockdep warnings, or crashes.

Typical attack path

1. Obtain local execution on a Linux host or inside a container/network namespace with permission to manage traffic control objects.
2. Create traffic control qdiscs, filters, and associated actions through rtnetlink/tc operations.
3. Run concurrent threads or processes that repeatedly add filters while deleting filters/actions to trigger the NEWTFILTER versus DELFILTER race.
4. Attempt to win the race so one path holds or uses a stale tc_action pointer after another path has removed and freed it.
5. Use the resulting use-after-free to crash the kernel, or combine it with heap grooming to attempt privilege escalation.
6. Clean up visible traffic control state and temporary tooling if stealth is desired.

How to detect it

Look for evidence of attempted or successful exploitation in host telemetry and kernel logs rather than relying on network perimeter logs, because exploitation is local through kernel traffic-control interfaces. Review dmesg, journald, /var/log/kern.log, /var/log/messages, auditd, EDR process telemetry, and container runtime logs for bursts of tc or rtnetlink activity followed by kernel warnings, KASAN reports, page faults, general protection faults, refcount anomalies, or reboots. Pay special attention to commands or processes repeatedly adding and deleting traffic-control filters/actions, particularly from unexpected users, containers, CI jobs, or service accounts. If auditd or eBPF telemetry is available, search for invocations of tc, iproute2, or custom binaries issuing RTM_NEWTFILTER and RTM_DELTFILTER netlink messages. For forensic review after a crash, inspect vmcore/kdump data for stack traces involving net/sched action code, tcf_action cleanup, idr lookup/removal, refcount operations, or kfree of tc_action-related objects. There are no known public exploit-specific file names, payload hashes, or network signatures in the provided data, so treat the indicators below as behavioral and crash-artifact leads rather than definitive compromise proof.

• KASAN: use-after-free
• BUG: KASAN: use-after-free
• general protection fault
• kernel BUG at net/sched
• Oops:
• refcount_t: addition on 0
• refcount_t: underflow
• tcf_action
• tcf_action_cleanup
• tcf_action_init
• tcf_action_destroy
• tcf_del_walker
• tc_ctl_tfilter
• RTM_NEWTFILTER
• RTM_DELTFILTER
• /sbin/tc
• /usr/sbin/tc
• tc filter add
• tc filter del
• tc actions add
• tc actions del
• CAP_NET_ADMIN

What your security team should do

• Prioritize patching multi-user Linux systems, Kubernetes/container nodes, CI runners, bastion hosts, and systems that grant CAP_NET_ADMIN to users or workloads.
• Inventory hosts and images running Linux kernels that do not yet include the net/sched tc_action RCU deferred-free fix.
• Restrict CAP_NET_ADMIN and privileged containers; remove unnecessary permissions to create network namespaces or manage traffic control.
• Disable unprivileged user namespaces where compatible with business requirements, especially on shared systems.
• Monitor kernel logs for net/sched, tc_action, KASAN, general protection fault, use-after-free, or kernel oops messages until remediation is complete.
• Ensure golden images, container host images, and appliance firmware are rebuilt with fixed kernels so vulnerable versions are not reintroduced.
• Because this issue is not KEV-listed and has low EPSS in the provided data, treat it as important defense-in-depth rather than an emergency internet-facing patch, unless local untrusted users or privileged containers are present.