CVE-2026-53267

What it actually does

This is a Linux kernel netfilter/nftables stack buffer overflow in the conntrack expression handling path. A crafted nftables rule sequence can cause nft_ct_get_eval() or related fast-evaluation logic to treat a conntrack template object as a fully initialized conntrack entry and copy more address data than the destination nftables register can safely hold. The result is corruption of adjacent kernel stack memory in struct nft_regs. Depending on kernel build, mitigations, register placement, and attacker control, the likely outcomes range from kernel crash and denial of service to potential local privilege escalation through controlled kernel memory corruption.

Why it matters to the business

Systems that allow untrusted or semi-trusted users, containers, or workloads to create nftables rules could be exposed to host instability or possible host compromise. The risk is highest on Linux hosts where CAP_NET_ADMIN is available inside containers, unprivileged user namespaces are enabled in ways that permit nftables manipulation, or firewall automation accepts untrusted rule input. EPSS is currently low, it is not listed in CISA KEV, and no public exploit maturity is reported, but kernel memory-corruption bugs should still be prioritized because successful exploitation can affect the whole host.

How an attack unfolds

An attacker first needs a path to install or modify nftables rules, usually through root privileges, CAP_NET_ADMIN, a privileged container, or a namespace configuration that exposes netfilter administration. They create a rule sequence where one conntrack expression attaches a per-CPU template conntrack object to a packet, such as by setting a conntrack zone, and a subsequent conntrack get expression reads original source or destination address fields from that same packet state. Vulnerable kernels fail to reject the template object and use an unsafe length decision when copying address data into nftables registers. By influencing the destination register layout, the attacker can cause the copy to overrun the nftables register structure on the kernel stack. In simple cases this crashes the kernel; in more advanced exploitation attempts it may corrupt kernel stack state in a way that could be used for privilege escalation. Exploitation is local or administrative-plane focused rather than remotely triggerable by ordinary network packets alone, because the attacker must be able to load the malicious nftables program.

How to fix it

Upgrade to a kernel version or distribution backport that contains the netfilter fix rejecting template conntrack objects in nft_ct_get_eval() and nft_ct_get_fast_eval(), and bounding NFT_CT_SRC/NFT_CT_DST address copies by the validated nftables expression length. If an exact fixed package version is not available from upstream metadata, use the latest security kernel from the relevant Linux distribution and confirm its changelog references the netfilter/nft_ct template conntrack fix. Reboot into the fixed kernel after installation. As interim mitigation, restrict CAP_NET_ADMIN, avoid privileged containers unless strictly required, disable or limit unprivileged user namespaces where operationally feasible, prevent untrusted users from loading nftables rules, and review automation that accepts user-controlled firewall rule definitions. Do not rely on network filtering alone, because the vulnerable condition is caused by local rule installation rather than a specific remote packet signature.

How to confirm the fix worked

Confirm the running kernel is the patched kernel, not merely that an updated package is installed. Validate with uname and distribution package tools, then compare against the vendor advisory or changelog for the netfilter nft_ct fix. Inspect nftables rulesets for unexpected conntrack expressions that set zones and then immediately read conntrack original source or destination address fields, especially in raw/prerouting chains. Where safe, test in a non-production environment that the previously crashing rule pattern is rejected or no longer causes kernel warnings, KASAN reports, or crashes. Confirm that container and user namespace policies do not grant nftables administration to workloads that should not have host-impacting network administration rights.

Typical attack path

1. Gain the ability to create or alter nftables rules, such as root access, CAP_NET_ADMIN, a privileged container, or permissive namespace configuration.
2. Install an nftables table and chain on a packet-processing hook such as prerouting.
3. Add a conntrack expression that creates or attaches a conntrack template, for example by setting a conntrack zone.
4. Add a following conntrack expression that reads original source or destination address fields from the same packet context.
5. Trigger evaluation of the chain with matching traffic or local packet generation.
6. Exploit the vulnerable copy path to corrupt kernel stack memory, causing a kernel crash or potentially enabling further privilege-escalation primitives.

How to detect it

There is no reliable remote network indicator because exploitation depends on installing a malicious local nftables rule sequence. Focus on administrative and host telemetry. Review auditd, systemd-journald, EDR process logs, shell history, sudo logs, container runtime logs, and configuration management records for nft or nftables commands that add conntrack expressions, particularly combinations of ct zone set with ct original saddr or ct original daddr. Inspect current and historical nftables rulesets where available. Review kernel logs for crashes or memory-safety reports around netfilter conntrack evaluation, including KASAN stack-out-of-bounds, general protection faults, kernel BUG/Oops, panic events, and call traces containing nft_ct_get_eval, nft_ct_get_fast_eval, nft_ct_set_zone_eval, nf_ct_tmpl_alloc, or nf_tables. In containerized environments, investigate workloads granted CAP_NET_ADMIN or privileged mode shortly before kernel instability. Treat unexplained host crashes following nftables rule changes as suspicious and preserve kernel logs, vmcore/kdump output, audit logs, and the active ruleset for forensic review.

• ct zone set
• ct original saddr
• ct original daddr
• type filter hook prerouting priority raw
• nft add rule
• nft -f
• nft_ct_get_eval
• nft_ct_get_fast_eval
• nft_ct_set_zone_eval
• nf_ct_tmpl_alloc
• BUG: KASAN: stack-out-of-bounds
• KASAN: stack-out-of-bounds
• general protection fault
• kernel BUG
• Oops:
• nf_tables
• nft_ct
• CAP_NET_ADMIN
• /etc/nftables.conf
• /etc/sysconfig/nftables.conf
• /var/lib/nftables/
• /usr/sbin/nft
• /sbin/nft

What your security team should do

• Prioritize patching Linux systems that run containers, multi-tenant workloads, CI/CD runners, network appliances, Kubernetes nodes, or services where CAP_NET_ADMIN may be delegated.
• Inventory hosts where unprivileged user namespaces, privileged containers, or CAP_NET_ADMIN are enabled and treat those as higher-risk exposure points.
• Search audit, EDR, shell history, and process execution telemetry for recent nft or nftables rule changes involving conntrack zone setting and conntrack original source or destination reads.
• Review existing nftables rulesets for suspicious or unnecessary conntrack expressions, especially recently added raw/prerouting rules.
• Add monitoring for kernel crashes, KASAN stack-out-of-bounds reports, and call traces involving nft_ct_get_eval, nft_ct_get_fast_eval, nft_ct_set_zone_eval, or nf_ct_tmpl_alloc.
• Restrict nftables administration to trusted automation and administrators; remove CAP_NET_ADMIN from containers by default.
• Because EPSS is low, KEV is false, and public exploit maturity is currently reported as none, balance urgency against exposure, but do not defer patching on systems where untrusted users can influence nftables rules.