CVE-2026-52970

What it actually does

This is a Linux kernel netfilter/nftables conntrack expectation reference leak. The vulnerable nft_ct_expect_obj_eval() path allocates a connection-tracking expectation and may register it with nf_ct_expect_related(), but fails to release its local reference before returning. Repeated evaluation can leave expectation objects referenced longer than intended, consuming kernel memory or conntrack-related resources. The practical impact is denial of service through resource exhaustion, not code execution or direct privilege escalation based on the available information.

Why it matters to the business

Systems using affected Linux kernels with nftables/netfilter conntrack expectation functionality may become unstable, run out of kernel memory, drop network traffic, or require reboot. The risk is currently lower than many internet-facing vulnerabilities because there is no known public exploit, it is not in CISA KEV, EPSS is low, and exploitation generally requires the relevant nftables rule path or elevated network administration capability. However, Linux kernel issues can have broad operational impact because kernels are widely embedded across servers, appliances, containers hosts, and network infrastructure.

How an attack unfolds

An attacker first needs a way to cause the vulnerable nftables conntrack expectation evaluation path to run. In many environments this would require local administrative networking privileges, such as CAP_NET_ADMIN, the ability to load or modify nftables rules, or access through a privileged container or network namespace configuration. If vulnerable conntrack expectation rules are already present, traffic that matches those rules may also exercise the flawed path. The attacker repeatedly triggers rule evaluation so the kernel allocates conntrack expectation objects without dropping the local reference. Over time, leaked references consume kernel memory or conntrack resources, causing degraded networking, allocation failures, service disruption, or a system-wide denial of service.

How to fix it

Apply the Linux kernel update from the operating system or appliance vendor that includes the upstream fix adding nf_ct_expect_put(exp) in nft_ct_expect_obj_eval(). Because this is a kernel fix, ensure the system is rebooted into the patched kernel after installation. If exact fixed package versions are not available, track the relevant vendor advisory for CVE-2026-52970 and confirm the running kernel build includes the netfilter nft_ct expectation reference leak fix. As temporary mitigation, restrict nftables administration to trusted administrators only, remove unnecessary nftables conntrack expectation/helper rules, avoid granting CAP_NET_ADMIN to untrusted containers or workloads, and monitor conntrack expectation and kernel memory growth on systems that cannot be patched immediately.

How to confirm the fix worked

Confirm the host is running a kernel version or vendor package that contains the nft_ct_expect_obj_eval() reference leak fix, not merely that the package has been installed. Validate with the running kernel version after reboot, for example through standard OS package inventory and uname -r. Review the active nftables ruleset for use of conntrack expectation functionality and remove it where unnecessary. On systems where exposure remains, monitor /proc/slabinfo, conntrack expectation counts, kernel memory pressure, and nftables rule activity before and after patching; repeated packet evaluation should not cause unbounded growth in conntrack expectation-related allocations. In lab validation, reproduce only in a controlled environment by exercising affected nftables conntrack expectation rules and confirming resource usage remains stable on the patched kernel.

Typical attack path

1. Obtain access to a local account, container, management plane, or automation path that can influence nftables/netfilter configuration or traffic hitting existing vulnerable conntrack expectation rules.
2. Identify whether the host is running an affected Linux kernel and has nftables conntrack expectation functionality available or configured.
3. Create, modify, or abuse nftables rules that invoke conntrack expectation object evaluation, or send traffic that repeatedly matches an existing vulnerable rule path.
4. Repeatedly trigger the vulnerable evaluation path to accumulate unreleased conntrack expectation references.
5. Cause kernel memory or conntrack resource exhaustion, resulting in network disruption, service instability, or host denial of service.

How to detect it

Historical exploitation is difficult to prove because the flaw is a kernel reference leak and may not leave a unique compromise artifact. Review kernel logs, system logs, audit logs, EDR telemetry, shell history, and configuration-management logs for nftables rule changes or repeated execution of nft commands around periods of network instability, memory pressure, or reboots. Focus on signs of resource exhaustion: OOM killer activity, conntrack expectation growth, slab memory growth, netfilter errors, packet drops, service timeouts, and unexpected system restarts. If auditd or EDR captures process execution, look for nft, iptables-nft, firewalld, container runtimes, orchestration agents, or custom scripts changing nftables rules before the outage. On container hosts, investigate workloads granted CAP_NET_ADMIN or privileged mode. If packet telemetry is available, correlate spikes in traffic matching nftables conntrack expectation/helper rules with kernel memory growth or network degradation. There are no known named threat actors or public exploitation campaigns associated with this vulnerability in the provided data.

• nft
• iptables-nft
• nft list ruleset
• nft -f
• ct expectation
• nf_conntrack_expect
• nf_conntrack: expectation table full
• Out of memory: Killed process
• oom-killer
• invoked oom-killer
• Memory allocation failure
• NETLINK_NETFILTER
• CAP_NET_ADMIN
• /proc/slabinfo
• /proc/net/nf_conntrack_expect

What your security team should do

• Prioritize patching internet-facing Linux systems, network appliances, container hosts, firewall hosts, and systems where untrusted users or workloads may have CAP_NET_ADMIN or nftables control.
• Verify that patched systems have rebooted into the fixed kernel; do not rely solely on package installation status.
• Audit privileged containers, Kubernetes workloads, systemd services, and automation accounts for CAP_NET_ADMIN or nftables modification rights and remove unnecessary privileges.
• Inventory nftables rulesets for conntrack expectation/helper usage and disable unnecessary rules until kernels are patched.
• Monitor for unusual nft command execution, netlink firewall rule changes, conntrack expectation growth, kernel memory pressure, OOM events, and unexplained network disruption.
• Treat exploitation likelihood as currently low because EPSS is low, no public exploit maturity is reported, and it is not KEV; still address in normal kernel patch cycles because successful exploitation can disrupt critical services.