CVE-2026-64581: xfrm: fix sk_dst_cache double-free in xfrm_user_policy()

CVE-2026-64581: xfrm: fix sk_dst_cache double-free in xfrm_user_policy()

[Greg Kroah-Hartman]

From: Greg Kroah-Hartman <gregkh@kernel.org>

Description
===========

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 socket's 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.

The Linux kernel CVE team has assigned CVE-2026-64581 to this issue.


Affected and fixed versions
===========================

	Issue introduced in 4.14 with commit 2b06cdf3e688b98fcc9945873b5d42792bd4eee0 and fixed in 7.1.6 with commit 96b678d08268b5f5c6fc99d4289d9b7e334fc683
	Issue introduced in 4.14 with commit 2b06cdf3e688b98fcc9945873b5d42792bd4eee0 and fixed in 7.2-rc4 with commit c283e9ada7fcb7dd4b10592623086b2e6d2f9925
	Issue introduced in 3.16.52 with commit 72f157be2f81910ae759bfe2e5c2256fc4625645
	Issue introduced in 4.4.163 with commit 9e9fe58a92a46c6d154d2901735bf230d91b8507
	Issue introduced in 3.18.101 with commit adc1ec6cdc20d430aa01b86497220709b9149466
	Issue introduced in 4.1.52 with commit b54033eb1cfd77aba471269ddd804ed8d3e35dea
	Issue introduced in 4.4.123 with commit c9e82cb34c3c2ee895af01bc899c6ed0bc6eb04a
	Issue introduced in 4.9.89 with commit 5eef9b51114fcc65651d671add52f267f91b9451

Please see https://www.kernel.org for a full list of currently supported
kernel versions by the kernel community.

Unaffected versions might change over time as fixes are backported to
older supported kernel versions.  The official CVE entry at
	https://cve.org/CVERecord/?id=CVE-2026-64581
will be updated if fixes are backported, please check that for the most
up to date information about this issue.


Affected files
==============

The file(s) affected by this issue are:
	net/xfrm/xfrm_state.c


Mitigation
==========

The Linux kernel CVE team recommends that you update to the latest
stable kernel version for this, and many other bugfixes.  Individual
changes are never tested alone, but rather are part of a larger kernel
release.  Cherry-picking individual commits is not recommended or
supported by the Linux kernel community at all.  If however, updating to
the latest release is impossible, the individual changes to resolve this
issue can be found at these commits:
	https://git.kernel.org/stable/c/96b678d08268b5f5c6fc99d4289d9b7e334fc683
	https://git.kernel.org/stable/c/c283e9ada7fcb7dd4b10592623086b2e6d2f9925