linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: Artem Dinaburg <artem@trailofbits.com>
Cc: stable@vger.kernel.org, Xiang Mei <xmei5@asu.edu>,
	Steffen Klassert <steffen.klassert@secunet.com>,
	Herbert Xu <herbert@gondor.apana.org.au>,
	linux-kernel@vger.kernel.org,
	AutonomousCodeSecurity@microsoft.com
Subject: Re: [PATCH 6.1.y] xfrm: fix sk_dst_cache double-free in xfrm_user_policy()
Date: Mon, 24 Aug 2026 15:45:47 +0200	[thread overview]
Message-ID: <2026082450-eggshell-gigantic-97d2@gregkh> (raw)
In-Reply-To: <20260821044210.10076-1-artem@trailofbits.com>

On Fri, Aug 21, 2026 at 12:42:00AM -0400, Artem Dinaburg wrote:
> From: Xiang Mei (Microsoft) <xmei5@asu.edu>
> 
> [ Upstream commit c283e9ada7fcb7dd4b10592623086b2e6d2f9925 ]
> 
> 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.
> 
> Fixes: 2b06cdf3e688 ("xfrm: Clear sk_dst_cache when applying per-socket policy.")
> Fixes: be8f8284cd89 ("net: xfrm: allow clearing socket xfrm policies.")
> Reported-by: AutonomousCodeSecurity@microsoft.com
> Signed-off-by: Xiang Mei (Microsoft) <xmei5@asu.edu>
> Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
> Assisted-by: Codex:GPT-5
> Signed-off-by: Artem Dinaburg <artem@trailofbits.com>
> ---
> Please queue this unchanged upstream fix for CVE-2026-64581 in 6.1.y. An
> unprivileged namespace user can race UDP transmit with per-socket XFRM policy
> replacement and double-release the cached destination.
> 
> Reproduced immediately on KASAN v6.1.182; the patched target completed 50,000
> rounds. The fix is in 7.1.6 but absent from 6.1.y.

Yes, but we need it also for all other trees between those versions.
You do not want to upgrade from the 6.1.y tree to 6.6.y and have a
regression, right?

Please submit all needed backports, including this one again, and we'll
be glad to queue them up then.

thanks,

greg k-h

  reply	other threads:[~2026-08-24 13:45 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-21  4:42 [PATCH 6.1.y] xfrm: fix sk_dst_cache double-free in xfrm_user_policy() Artem Dinaburg
2026-08-24 13:45 ` Greg KH [this message]
2026-08-25 11:49 ` Sasha Levin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2026082450-eggshell-gigantic-97d2@gregkh \
    --to=gregkh@linuxfoundation.org \
    --cc=AutonomousCodeSecurity@microsoft.com \
    --cc=artem@trailofbits.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=linux-kernel@vger.kernel.org \
    --cc=stable@vger.kernel.org \
    --cc=steffen.klassert@secunet.com \
    --cc=xmei5@asu.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).