CVE-2026-53212

What it actually does

This is a Linux kernel use-after-free in the netfilter nft_tunnel object lifecycle. When an nftables tunnel metadata object is destroyed, the vulnerable code frees a metadata_dst object directly instead of releasing it through the dst reference-counting path. If packets have already taken a reference to that destination metadata and remain queued, for example in a netem traffic-control queue, later packet dequeue can call dst_release() on memory that has already been freed. The most likely outcomes are kernel memory corruption and kernel crash; under favorable heap-shaping conditions, a local attacker with the ability to manipulate nftables/netfilter and traffic-control state may be able to escalate privileges or execute code in kernel context.

Why it matters to the business

Successful exploitation can destabilize Linux systems by triggering kernel crashes, causing service outages, workload interruption, and possible node reboots. Because exploitation requires local or namespace-level administrative networking capabilities, broad internet-facing exposure is unlikely, but shared Linux hosts, container platforms, CI runners, lab systems, and environments that allow unprivileged user namespaces or delegated network administration have higher practical risk. The issue is not currently listed in CISA KEV, is not reported as used in ransomware, has no stated exploit maturity, and has a low EPSS score, so remediation should be prioritized as part of normal kernel security maintenance unless local multi-tenant exposure or untrusted container workloads are present.

How an attack unfolds

An attacker first needs a local execution foothold with the ability to create or modify nftables tunnel objects and influence packet queuing, typically through CAP_NET_ADMIN in a network namespace or an equivalent privileged container/container-host configuration. The attacker configures nftables rules that use nft_tunnel metadata and arranges for packets to traverse the rule path so references are taken to the metadata destination object. They then keep packets queued, such as by using a netem qdisc, and destroy the nft_tunnel object while queued packets still hold references. On vulnerable kernels, object destruction frees the metadata_dst immediately instead of waiting for all references to drain. When queued packets later leave the qdisc and the networking stack releases their destination reference, the kernel touches freed memory. Depending on timing and memory layout, this can produce an immediate kernel oops/panic or potentially be shaped into a kernel memory-corruption primitive.

How to fix it

Upgrade to a Linux kernel build that includes the upstream fix replacing metadata_dst_free() with dst_release() in nft_tunnel_obj_destroy(). Because fixed package versions were not provided, use the latest security kernel from the relevant Linux distribution or vendor advisory and reboot into the fixed kernel. Where immediate patching is not possible, reduce exposure by limiting CAP_NET_ADMIN, disabling or restricting unprivileged user namespaces where operationally feasible, preventing untrusted containers from creating network namespaces or nftables rules, and tightly controlling use of traffic-control qdiscs such as netem on production hosts. Removing or avoiding nft_tunnel object usage may reduce triggerability but should not be treated as a complete substitute for patching.

How to confirm the fix worked

Confirm the running kernel is the patched vendor build, not merely that a patched package is installed; validate with kernel package inventory and the active kernel version after reboot. Review vendor advisories or kernel changelogs for the netfilter nft_tunnel fix mentioning nft_tunnel_obj_destroy(), metadata_dst_free(), dst_release(), or use-after-free on object destroy. On source-based or custom kernels, verify that nft_tunnel_obj_destroy() releases metadata_dst through dst_release() rather than directly freeing it. Also validate exposure controls by confirming untrusted users and containers lack CAP_NET_ADMIN, cannot create nftables objects, and cannot configure netem qdiscs unless explicitly required.

Typical attack path

1. Gain local code execution on a Linux system or inside a network namespace with sufficient network administration capability.
2. Create nftables rules or objects that use nft_tunnel metadata handling.
3. Generate traffic that traverses the nft_tunnel rule path so packets hold references to metadata_dst state.
4. Use packet queuing or delay mechanisms, such as a netem qdisc, to keep affected packets in flight.
5. Destroy the nft_tunnel object while queued packets still reference its metadata destination.
6. Allow queued packets to dequeue, causing dst_release() to operate on freed memory.
7. Trigger kernel crash, denial of service, or attempt further exploitation of kernel memory corruption.

How to detect it

Look for signs of kernel memory corruption or crashes around netfilter tunnel metadata handling. Primary sources are kernel logs, journald, dmesg, crash dumps, kdump/vmcore analysis, auditd exec records, shell history from administrative accounts, container runtime audit logs, and EDR telemetry for nft and tc command execution. Relevant artifacts include kernel oops/panic traces with nft_tunnel_obj_destroy(), nft_tunnel_obj_eval(), metadata_dst_free(), dst_release(), dst_destroy(), or netem in the stack; KASAN or slab allocator use-after-free reports involving metadata_dst or dst_entry; unexpected creation and deletion of nft tunnel objects; and use of tc qdisc netem shortly before a kernel crash. Because there are no public attacker-specific indicators in the provided intelligence and exploitation is timing-dependent local kernel behavior, detection should focus on behavioral correlation: nftables tunnel object manipulation plus packet-delay qdisc configuration followed by kernel instability.

• nft_tunnel_obj_destroy
• nft_tunnel_obj_eval
• metadata_dst_free
• metadata_dst
• dst_release
• dst_destroy
• DST_METADATA
• BUG: KASAN: use-after-free
• use-after-free in dst_release
• general protection fault
• kernel NULL pointer dereference
• kernel panic
• Oops:
• slab-use-after-free
• netem
• tc qdisc add
• tc qdisc change
• tc qdisc replace
• nft add object
• nft delete object
• nft_tunnel

What your security team should do

• Patch affected Linux kernels during the next security maintenance window, and prioritize faster patching for multi-tenant hosts, container platforms, CI infrastructure, and systems permitting unprivileged user namespaces.
• Inventory systems where nftables, network namespaces, CAP_NET_ADMIN delegation, privileged containers, or traffic-control netem are enabled.
• Restrict CAP_NET_ADMIN and privileged container use to trusted workloads only.
• Disable or limit unprivileged user namespaces where compatible with business requirements.
• Monitor for kernel oops, panic, KASAN, or slab corruption messages referencing nft_tunnel, metadata_dst, dst_release, or netem.
• Review recent administrative activity for unusual nft and tc/netem changes, especially from nonstandard automation or user sessions.
• For custom kernels, backport the upstream fix if a vendor-patched kernel is not immediately available.