CVE-2026-72137: Double Free in Linux Kernel XFRM NAT Keepalive

The Linux kernel IPsec framework (XFRM) subsystem implements Network Address Translation (NAT) keepalives to maintain stateful NAT bindings for UDP-encapsulated Encapsulating Security Payload (ESP) traffic. When configured, this subsystem periodically generates keepalive packets to prevent intermediate NAT gateways from expiring connection states.

This background keepalive mechanism uses nat_keepalive_send() to allocate, format, and dispatch socket buffer structures (sk_buff) down the network stack. A critical software flaw in this interface allows an allocated socket buffer to be freed twice under specific error conditions. This vulnerability is classified as a double-free memory corruption issue (CWE-415).

The vulnerability is triggered when the IPv4 or IPv6 helper functions encounter a transmission error after the networking stack has assumed ownership of the socket buffer. An attacker capable of inducing network-level or routing-level errors during keepalive transmission can exploit this vulnerability to corrupt kernel memory allocator structures, resulting in a system crash or potentially local privilege escalation.

In the Linux kernel's networking stack, socket buffer (sk_buff or skb) lifetime management is governed by strict ownership rules. When a socket buffer is passed to a downstream transmission function such as ip_build_and_send_pkt() or ip6_xmit(), the ownership of that structure is transferred to the receiving subsystem. If an error occurs during downstream processing, the receiving subsystem is responsible for freeing the skb and propagating the error code back up the execution chain.

Prior to the patch, the nat_keepalive_send() function in net/xfrm/xfrm_nat_keepalive.c violated these ownership rules. The function dispatched the skb to family-specific helper functions (nat_keepalive_send_ipv4() or nat_keepalive_send_ipv6()) and monitored the return code. If the helpers returned an error, the caller assumed it still owned the packet and invoked kfree_skb(skb) to clean up the buffer.

However, if the error was encountered after the helper had already passed the skb to the downstream transmission functions, those downstream functions had already executed their own cleanup paths, freeing the skb internally. Consequently, the secondary call to kfree_skb() inside nat_keepalive_send() attempted to free an already deallocated memory chunk. This pattern triggers a classic double-free condition within the kernel slab or slub allocator.

The remediation of this vulnerability involves restructuring the boundaries of socket buffer ownership within the NAT keepalive execution path. The patch moves the cleanup responsibility of the sk_buff structure into the individual IPv4 and IPv6 helper functions, isolating the main caller from downstream state changes.

// In net/xfrm/xfrm_nat_keepalive.c
static int nat_keepalive_send_ipv4(struct sk_buff *skb,
				   struct nat_keepalive *ka)
{
	// ...
	rt = ip_route_output_key(net, &fl4);
- 	if (IS_ERR(rt))
+ 	if (IS_ERR(rt)) {
+ 		kfree_skb(skb); // Free skb if route lookup fails before handoff
		return PTR_ERR(rt);
+ 	}

static void nat_keepalive_send(struct nat_keepalive *ka)
{
	// ...
	switch (ka->family) {
	case AF_INET:
- 		err = nat_keepalive_send_ipv4(skb, ka);
+ 		nat_keepalive_send_ipv4(skb, ka); // Caller no longer tracks error for cleanup
		break;
#if IS_ENABLED(CONFIG_IPV6)
	case AF_INET6:
- 		err = nat_keepalive_send_ipv6(skb, ka, uh);
+ 		nat_keepalive_send_ipv6(skb, ka, uh);
		break;
#endif
+	default:
+		kfree_skb(skb); // Clean up only if address family is completely unsupported
+		break;
	}
- 	if (err)
- 		kfree_skb(skb); // REMOVED: No longer double-frees skb on downstream errors
}

By refactoring the code, the caller nat_keepalive_send() is restricted to allocating the buffer, dispatching it to the helpers, and freeing it only in the default case where the IP family is unsupported. If a routing or translation error occurs pre-handoff inside nat_keepalive_send_ipv4() or nat_keepalive_send_ipv6(), the helper frees the buffer locally. If the handoff is successful, the downstream networking layers handle memory deallocation entirely, ensuring no double-free condition can be triggered.

Exploitation of this vulnerability requires specific environmental and configuration prerequisites. The target system must be configured to use IPsec (XFRM) with NAT keepalives active. This occurs typically in environments using UDP-encapsulated ESP (IPsec NAT-Traversal) to bypass network address translation gateways.

To trigger the vulnerable code path, an attacker must induce a transmission error after the socket buffer has been handed off to the IP routing or output queues. This state can be forced by dynamically altering the host's routing tables, or by inducing rapid link-state transitions (interface flapping) during the keepalive interval. If the downstream stack encounters a routing lookup or transmission failure, it frees the packet and returns an error code, triggering the second free in the unpatched keepalive caller.

No public proof-of-concept (PoC) code or weaponized exploits currently exist for this vulnerability. In a local privilege escalation scenario, an attacker could attempt a heap spray attack targeting the kmalloc-X slab caches used for socket buffers. By placing structured payloads in the deallocated memory slot between the first and second free operations, the second free could release a control-structure buffer, facilitating a use-after-free (UAF) condition that enables kernel control-flow hijacking.

The security impact of a kernel-level double-free vulnerability is severe, as reflected in its CVSS score of 9.8. Because the flaw exists within the core memory allocator of the Linux kernel, any execution of the vulnerable path corrupts the allocator's internal tracking lists (such as the SLUB freelist pointers). This corruption typically leads to immediate kernel panic, causing a complete denial of service (DoS) for the affected host.

Beyond denial of service, memory corruption vulnerabilities of this class can be leveraged for privilege escalation. If an attacker can control the layout of the kernel heap during the execution of the double-free sequence, they may manipulate allocator metadata to return overlapping memory chunks. This enables arbitrary write capabilities in kernel space, allowing an unprivileged local user to escalate privileges to root or execute arbitrary kernel code.

The remote exploitation vector is limited by the requirement to trigger a send error on the keepalive path. While the CVSS vector identifies Network (AV:N) access, triggering the failure path from a remote position is highly complex and depends on the attacker's ability to manipulate the host's route resolution or network interfaces. Consequently, the practical risk is highest in scenarios where a local attacker or a compromised container has access to raw sockets or routing parameters.

The primary and recommended mitigation is the application of the official Linux kernel patches. The vulnerability has been resolved in the main development branch and backported to active stable branches. Systems running the 6.12, 6.13, 6.18, or 7.1 stable branches must be upgraded to version 6.12.101, 6.18.40, 7.1.5, or newer, respectively.

In environments where immediate kernel upgrades are not feasible, administrative workarounds can be applied to reduce exposure. Administrators can disable UDP-encapsulated IPsec (NAT-Traversal) if it is not strictly required by the environment's network architecture. Disabling NAT-T prevents the initialization of the XFRM keepalive workers, effectively closing the vulnerable code path.

Additionally, restricting access to network configuration capabilities helps mitigate local exploitation. Ensuring that containers and unprivileged local users do not possess the CAP_NET_ADMIN capability limits their ability to manipulate routing tables or interface states. This restriction prevents the dynamic network manipulation required to trigger the downstream transmission errors that lead to the double-free condition.