CVE-2026-64581

In the Linux kernel, the following vulnerability has been resolved:

xfrm: fix sk_dst_cache double-free in xfrm_user_policy()

xfrm_user_policy() clears the socket dst cache with __sk_dst_reset(), i.e. the non-atomic __sk_dst_set(sk, NULL): it reads sk_dst_cache with rcu_dereference_protected(), stores NULL and dst_release()s the old dst. That is only safe if no other thread modifies sk_dst_cache concurrently.

For a connected UDP socket that does not hold: the transmit fast path (udp_sendmsg -> sk_dst_check -> sk_dst_reset) resets the cache locklessly with an atomic xchg(). A per-socket policy change racing a send can make both sides observe the same old dst and each dst_release() it, dropping the sockets single reference twice and freeing the xfrm_dst bundle while it is still referenced:

BUG: KASAN: slab-use-after-free in dst_release Write of size 4 at addr ffff88801897b6c0 by task exploit/155 Call Trace: … dst_release (… ./include/linux/rcuref.h:109) xfrm_user_policy (./include/net/sock.h:2239 ./include/net/sock.h:2256 net/xfrm/xfrm_state.c:3053) do_ip_setsockopt (net/ipv4/ip_sockglue.c:1347) ip_setsockopt (net/ipv4/ip_sockglue.c:1417) do_sock_setsockopt (net/socket.c:2368) __sys_setsockopt (net/socket.c:2393) __x64_sys_setsockopt (net/socket.c:2396) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121)

Reachable by an unprivileged user via a user+network namespace.

Use the atomic sk_dst_reset() so the cache is cleared and released with a single xchg(): whichever side wins releases the dst once, the other sees NULL and does nothing. Behaviour is otherwise unchanged.

Weakness

The product contains a concurrent code sequence that requires temporary, exclusive access to a shared resource, but a timing window exists in which the shared resource can be modified by another code sequence operating concurrently.

Affected Software

Extended Description

A race condition occurs within concurrent environments, and it is effectively a property of a code sequence. Depending on the context, a code sequence may be in the form of a function call, a small number of instructions, a series of program invocations, etc. A race condition violates these properties, which are closely related:

A race condition exists when an “interfering code sequence” can still access the shared resource, violating exclusivity. The interfering code sequence could be “trusted” or “untrusted.” A trusted interfering code sequence occurs within the product; it cannot be modified by the attacker, and it can only be invoked indirectly. An untrusted interfering code sequence can be authored directly by the attacker, and typically it is external to the vulnerable product.

Potential Mitigations

• Minimize the usage of shared resources in order to remove as much complexity as possible from the control flow and to reduce the likelihood of unexpected conditions occurring.
• Additionally, this will minimize the amount of synchronization necessary and may even help to reduce the likelihood of a denial of service where an attacker may be able to repeatedly trigger a critical section (CWE-400).

Related Attack Patterns

• https://cwe.mitre.org/data/definitions/26.html
• https://cwe.mitre.org/data/definitions/29.html

References

• https://git.kernel.org/stable/c/0ea8f06454012d9e7f9c6e6253df710949bf6294
• https://git.kernel.org/stable/c/8dd8929b71c4f06c614f8f54c2cc070453faae16
• https://git.kernel.org/stable/c/96b678d08268b5f5c6fc99d4289d9b7e334fc683
• https://git.kernel.org/stable/c/a9340ebdc13f8bb5063c0bc0b037ee7e640d4ae9
• https://git.kernel.org/stable/c/c283e9ada7fcb7dd4b10592623086b2e6d2f9925
• https://git.kernel.org/stable/c/e8686fd8d18b99f3a9038683045b2f2338a7706d
• https://git.kernel.org/stable/c/f0ab9a71167bae308e05ab13b65e2007504a603f
• https://git.kernel.org/stable/c/f833821e4b52ab6335d443ede5fb79c38e61d19a