CVE-2026-46319

What it actually does

This is a Linux kernel use-after-free race in the traffic control connection-tracking action, act_ct. During tcf_ct_flow_table_get(), the kernel looks up a connection-tracking flow-table object under an RCU read-side critical section, but releases that protection before incrementing the object's reference count. A concurrent cleanup path can remove and free the same object before the reference count is taken, leaving later code operating on freed kernel memory. Successful exploitation can corrupt kernel memory and may allow a local attacker with the ability to exercise traffic-control connection-tracking paths to escalate privileges to root or crash the system.

Why it matters to the business

A successful attack can turn limited local access into full control of a Linux host, allowing data theft, tampering, persistence, disabling of security tools, or service disruption. The vulnerability is local rather than remotely reachable, is not currently listed in CISA KEV, has no known mature public exploit in the provided intelligence, and has a low EPSS score, but it affects privileged kernel code and should be treated as important on multi-user systems, container hosts, CI runners, and environments where users or workloads can obtain CAP_NET_ADMIN through network namespaces or container configuration.

How an attack unfolds

An attacker first obtains local code execution as a low-privileged user or compromised workload. They then gain access to traffic-control operations, commonly through CAP_NET_ADMIN, a permissive container configuration, or unprivileged user and network namespaces that grant network-administration capabilities inside the namespace. The attacker repeatedly creates, looks up, and tears down act_ct connection-tracking flow-table state using Linux traffic control so that one execution path returns a flow-table pointer while another path frees the same object. By winning the race between lookup and refcount acquisition, the attacker causes the kernel to use a freed tcf_ct_flow_table object. With heap grooming and repeated attempts, the freed memory may be replaced with attacker-influenced data, potentially converting the use-after-free into kernel memory corruption, privilege escalation, or a kernel panic.

How to fix it

Apply the vendor-supplied Linux kernel update that contains the act_ct RCU/refcount lifetime fix. Because no fixed package versions were provided in the input, use the fixed kernel versions published by the relevant Linux distribution, appliance vendor, cloud image provider, or kernel maintainer. Prioritize updates for multi-tenant Linux hosts, container platforms, systems that allow unprivileged user namespaces, developer workstations, CI/CD runners, and hosts where non-root users or containers can obtain CAP_NET_ADMIN. If immediate patching is not possible, reduce exposure by removing CAP_NET_ADMIN from containers and services that do not need it, disabling or restricting unprivileged user namespaces where operationally feasible, limiting access to the tc utility and netlink traffic-control APIs, preventing untrusted users from creating network namespaces, and unloading or preventing automatic loading of the act_ct module only if the system does not require traffic-control connection tracking.

How to confirm the fix worked

Confirm the running kernel is a vendor-fixed build, not only that an updated package is installed; reboot into the fixed kernel where required and verify with uname -r and the distribution package manager. Review the vendor changelog or kernel source to confirm the act_ct flow-table lookup keeps the object protected until refcount_inc_not_zero() succeeds or otherwise fixes the RCU lifetime gap in tcf_ct_flow_table_get(). Validate exposure reduction by confirming untrusted users and workloads cannot run traffic-control connection-tracking operations, do not have CAP_NET_ADMIN, and cannot create unprivileged network namespaces if those mitigations are intended. On systems where act_ct is not needed, verify the module is not loaded and cannot be auto-loaded by untrusted activity. Avoid attempting to validate with public exploit code on production systems because the bug can destabilize the kernel.

Typical attack path

1. Gain local execution on a Linux system as a non-root user or compromised workload.
2. Obtain or abuse the ability to perform network traffic-control operations, such as CAP_NET_ADMIN in the initial namespace or inside a network namespace/container.
3. Load or trigger use of the act_ct traffic-control connection-tracking action and related netfilter flow-table functionality.
4. Repeatedly create and delete traffic-control filters/actions that use connection tracking to force concurrent tcf_ct_flow_table_get() and cleanup activity.
5. Race the flow-table lookup against the cleanup worker so the returned object is freed before its reference count is incremented.
6. Groom kernel heap memory to influence the contents of the freed object.
7. Trigger use of the stale pointer to corrupt kernel memory, escalate privileges, or crash the host.

How to detect it

Post-exploitation detection is difficult because successful kernel use-after-free exploitation may leave few application-level artifacts. Focus on kernel telemetry, audit logs, process execution logs, container runtime events, and netlink/traffic-control activity. Review dmesg, journald, /var/log/kern.log, /var/log/messages, crash dumps, KASAN reports, and vmcores for use-after-free, refcount, RCU, general protection fault, kernel oops, or panic messages involving act_ct, tcf_ct_flow_table_get(), tcf_ct_flow_table_cleanup_work(), tcf_ct_flow_table_put(), nf_flow_table_free(), or rhashtable_lookup_fast(). Correlate those events with execution of tc, ip, unshare, nsenter, container runtime operations, module loads for act_ct, and unusual creation/deletion of qdisc/filter/action rules using connection tracking. In auditd or EDR process telemetry, look for non-administrative users or containers repeatedly invoking tc with 'action ct', creating network namespaces, or using CAP_NET_ADMIN unexpectedly. Also investigate privilege changes, new root-owned files, suspicious setuid binaries, unexpected kernel crashes followed by account compromise, or security-tool tampering around the same time. There are no provided threat actors, KEV listing, or known mature public exploit indicators, so detections should be behavior- and artifact-based rather than hash- or IP-based.

• BUG: KASAN: use-after-free
• use-after-free in tcf_ct_flow_table_get
• tcf_ct_flow_table_get
• tcf_ct_flow_table_cleanup_work
• tcf_ct_flow_table_put
• nf_flow_table_free
• rhashtable_lookup_fast
• act_ct
• sch_ingress
• action ct
• tc filter add
• tc actions add action ct
• tc actions replace action ct
• modprobe act_ct
• module act_ct
• ip netns add
• unshare --net
• unshare -n
• CAP_NET_ADMIN
• general protection fault
• kernel BUG
• kernel panic
• Oops:
• RCU

What your security team should do

• Inventory Linux systems that permit local shell access, host containers, run CI jobs, or allow unprivileged user/network namespaces, and prioritize those for kernel patching.
• Patch and reboot affected systems into a fixed kernel from the appropriate OS or appliance vendor.
• Remove CAP_NET_ADMIN from containers, services, and users unless explicitly required.
• Disable unprivileged user namespaces where feasible, especially on shared servers and container hosts.
• Monitor for unusual use of tc, ip netns, unshare, and repeated creation/deletion of traffic-control connection-tracking actions by non-administrative users or workloads.
• Search recent kernel logs for use-after-free, KASAN, kernel oops, or panic messages involving act_ct, tcf_ct_flow_table_get(), tcf_ct_flow_table_cleanup_work(), nf_flow_table_free(), or rhashtable lookup paths.
• Harden container runtime policies to prevent privileged containers, host networking, broad Linux capabilities, and arbitrary netlink traffic-control access.
• If act_ct is not operationally required, prevent the act_ct module from loading and verify there is no production dependency on tc connection-tracking actions.
• Treat unexplained kernel crashes on systems with local untrusted workloads as potentially security-relevant and preserve logs, vmcores, and audit records for investigation.