Re: [PATCH] ovpn: avoid putting unrelated P2P peer on socket release

[Simon Horman <horms@kernel.org>]

On Sat, May 23, 2026 at 04:15:43PM +0800, Qing Ming wrote:
> ovpn_peer_release_p2p() is called when an OVPN UDP socket is being
> destroyed. It checks the currently published P2P peer and releases it only
> if that peer still uses the socket being destroyed.
> 
> A peer replacement can publish a new peer before the old UDP socket is
> destroyed. When the old socket destruction path runs afterwards,
> ovpn_peer_release_p2p() observes the new peer through ovpn->peer. Since the
> new peer uses a different socket, the function takes the socket mismatch
> branch.
> 
> That branch still calls ovpn_peer_put(peer). At this point, however, peer
> is the currently published replacement peer, not the peer associated with
> the socket being destroyed. Dropping its reference can free it while
> ovpn->peer still points to it, leading to later use-after-free accesses
> from the peer and socket cleanup paths.
> 
> KASAN reports this as a slab-use-after-free on the kmalloc-1k ovpn_peer
> object. In the reproducer, the object is allocated from ovpn_peer_new() via
> ovpn_nl_peer_new_doit(), and freed through ovpn_peer_release_rcu() from RCU
> callback processing. Observed access sites include ovpn_peer_remove(),
> ovpn_socket_release(), ovpn_nl_peer_del_notify(), and unlock_ovpn().
> 
> Fix this by returning from the socket mismatch branch without putting the
> peer.
> 
> Fixes: f6226ae7a0cd ("ovpn: introduce the ovpn_socket object")
> Signed-off-by: Qing Ming <a0yami@mailbox.org>

It is probably not necessary to resubmit because of this,
but for future reference bug fixes for code present in the net tree
should be targeted at that tree like this:

	Subject: [PATCH net] ...

You can see more about the Networking development workflow here:
https://docs.kernel.org/process/maintainer-netdev.html


FTR, there is an AI-generated review of this patchset available on
sashiko.dev. I do not believe it should effect the progress of this patch.
But, rather, be considered in the context of possible follow-up.


Reviewed-by: Simon Horman <horms@kernel.org>