[PATCH net 1/2] ovpn: tcp - use cached peer pointer in ovpn_tcp_close()

[PATCH net 1/2] ovpn: tcp - use cached peer pointer in ovpn_tcp_close()

[David Carlier]

ovpn_tcp_close() loads the ovpn_socket via rcu_dereference_sk_user_data()
under rcu_read_lock(), takes a reference on sock->peer, caches the peer
pointer in a local, and drops the read lock. It then passes sock->peer
(rather than the cached local) to ovpn_peer_del(), re-dereferencing the
ovpn_socket after the RCU read section has ended.

Unlike ovpn_tcp_sendmsg(), which uses the same "load under RCU, use
after unlock" pattern but is protected by lock_sock() held across the
function, ovpn_tcp_close() runs without the socket lock: inet_release()
invokes sk_prot->close() without taking lock_sock first.

ovpn_socket_release() can therefore complete its kref_put -> detach ->
synchronize_rcu -> kfree(sock) sequence concurrently, in the window
after ovpn_tcp_close() drops rcu_read_lock() but before it dereferences
sock->peer. The synchronize_rcu() in ovpn_socket_release() protects
readers that use the dereferenced pointer inside the RCU read section,
not those that escape the pointer to a local and use it afterwards.

A reproducer follows the pattern of commit 94560267d6c4 ("ovpn: tcp -
don't deref NULL sk_socket member after tcp_close()"): trigger a peer
removal (keepalive expiration or netlink OVPN_CMD_DEL_PEER) at the same
moment userspace closes the TCP fd. That commit fixed the detach-side
of the same race window; this one fixes the close-side at a different
victim.

Use the already-loaded peer local, which is held by the
ovpn_peer_hold() taken under RCU and is the correct argument anyway.
The remaining lines in the function already use peer; switching this
call makes the function consistent and removes the dangling sock
dereference.

Fixes: 11851cbd60ea ("ovpn: implement TCP transport")
Assisted-by: Claude:claude-opus-4-7
Signed-off-by: David Carlier <devnexen@gmail.com>
---
 drivers/net/ovpn/tcp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ovpn/tcp.c b/drivers/net/ovpn/tcp.c
index 65054cc84be5..ed4782de141a 100644
--- a/drivers/net/ovpn/tcp.c
+++ b/drivers/net/ovpn/tcp.c
@@ -588,7 +588,7 @@ static void ovpn_tcp_close(struct sock *sk, long timeout)
 	peer = sock->peer;
 	rcu_read_unlock();
 
-	ovpn_peer_del(sock->peer, OVPN_DEL_PEER_REASON_TRANSPORT_DISCONNECT);
+	ovpn_peer_del(peer, OVPN_DEL_PEER_REASON_TRANSPORT_DISCONNECT);
 	peer->tcp.sk_cb.prot->close(sk, timeout);
 	ovpn_peer_put(peer);
 }
-- 
2.53.0

[PATCH net 2/2] ovpn: respect peer refcount in CMD_NEW_PEER error path

[David Carlier]

ovpn_nl_peer_new_doit()'s error path calls ovpn_peer_release() directly
rather than ovpn_peer_put(), bypassing the kref. The accompanying
comment ("peer was not yet hashed, thus it is not used in any context")
holds for UDP but not for TCP.

For UDP, the ovpn_socket union uses the .ovpn arm and never points back
at a peer; UDP encap_recv looks up peers via the not-yet-populated
hashtables, so the new peer is unreachable until ovpn_peer_add()
publishes it.

For TCP, ovpn_socket_new() sets ovpn_sock->peer and
ovpn_tcp_socket_attach() publishes ovpn_sock via rcu_assign_sk_user_data().
From that moment until ovpn_socket_release() detaches in the error path,
the TCP fd is fully wired: userspace recvmsg / sendmsg / close / poll
on the fd, as well as the strparser-driven ovpn_tcp_rcv() path, can
reach the peer through sk_user_data -> ovpn_sock->peer and bump its
refcount via ovpn_peer_hold().

ovpn_tcp_socket_wait_finish() (called inside ovpn_socket_release())
drains strparser and the tx work, but does not synchronize with
userspace syscall callers that already hold a peer reference. If
ovpn_nl_peer_modify() or ovpn_peer_add() returns an error while such
a caller is in flight - notably an ovpn_tcp_recvmsg() blocked in
__skb_recv_datagram() on peer->tcp.user_queue - the direct
ovpn_peer_release() destroys the peer while the caller still holds
the reference, and the eventual ovpn_peer_put() from that caller
operates on freed memory.

Replace the direct destructor call with ovpn_peer_put() so the kref
correctly defers destruction until the last reference is dropped.
In the common case where no concurrent user is present, behaviour is
unchanged: the kref hits zero immediately and ovpn_peer_release_kref()
runs the same destructor.

Fixes: 11851cbd60ea ("ovpn: implement TCP transport")
Assisted-by: Claude:claude-opus-4-7
Signed-off-by: David Carlier <devnexen@gmail.com>
---
 drivers/net/ovpn/netlink.c | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/net/ovpn/netlink.c b/drivers/net/ovpn/netlink.c
index 291e2e5bb450..4c66c1ec497e 100644
--- a/drivers/net/ovpn/netlink.c
+++ b/drivers/net/ovpn/netlink.c
@@ -462,10 +462,12 @@ int ovpn_nl_peer_new_doit(struct sk_buff *skb, struct genl_info *info)
 sock_release:
 	ovpn_socket_release(peer);
 peer_release:
-	/* release right away because peer was not yet hashed, thus it is not
-	 * used in any context
+	/* For UDP, the peer is unreachable until added to the hashtables, so
+	 * dropping the initial reference is enough. For TCP, the peer may be
+	 * concurrently reachable via sk_user_data->peer until
+	 * ovpn_socket_release() detaches; rely on the refcount.
 	 */
-	ovpn_peer_release(peer);
+	ovpn_peer_put(peer);
 
 	return ret;
 }
-- 
2.53.0

Re: [PATCH net 1/2] ovpn: tcp - use cached peer pointer in ovpn_tcp_close()

[Eric Dumazet]

On Mon, May 11, 2026 at 9:20 PM David Carlier <devnexen@gmail.com> wrote:
>
> ovpn_tcp_close() loads the ovpn_socket via rcu_dereference_sk_user_data()
> under rcu_read_lock(), takes a reference on sock->peer, caches the peer
> pointer in a local, and drops the read lock. It then passes sock->peer
> (rather than the cached local) to ovpn_peer_del(), re-dereferencing the
> ovpn_socket after the RCU read section has ended.
>
> Unlike ovpn_tcp_sendmsg(), which uses the same "load under RCU, use
> after unlock" pattern but is protected by lock_sock() held across the
> function, ovpn_tcp_close() runs without the socket lock: inet_release()
> invokes sk_prot->close() without taking lock_sock first.
>
> ovpn_socket_release() can therefore complete its kref_put -> detach ->
> synchronize_rcu -> kfree(sock) sequence concurrently, in the window
> after ovpn_tcp_close() drops rcu_read_lock() but before it dereferences
> sock->peer. The synchronize_rcu() in ovpn_socket_release() protects
> readers that use the dereferenced pointer inside the RCU read section,
> not those that escape the pointer to a local and use it afterwards.
>
> A reproducer follows the pattern of commit 94560267d6c4 ("ovpn: tcp -
> don't deref NULL sk_socket member after tcp_close()"): trigger a peer
> removal (keepalive expiration or netlink OVPN_CMD_DEL_PEER) at the same
> moment userspace closes the TCP fd. That commit fixed the detach-side
> of the same race window; this one fixes the close-side at a different
> victim.
>
> Use the already-loaded peer local, which is held by the
> ovpn_peer_hold() taken under RCU and is the correct argument anyway.
> The remaining lines in the function already use peer; switching this
> call makes the function consistent and removes the dangling sock
> dereference.
>
> Fixes: 11851cbd60ea ("ovpn: implement TCP transport")
> Assisted-by: Claude:claude-opus-4-7
> Signed-off-by: David Carlier <devnexen@gmail.com>
> ---
>  drivers/net/ovpn/tcp.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ovpn/tcp.c b/drivers/net/ovpn/tcp.c
> index 65054cc84be5..ed4782de141a 100644
> --- a/drivers/net/ovpn/tcp.c
> +++ b/drivers/net/ovpn/tcp.c
> @@ -588,7 +588,7 @@ static void ovpn_tcp_close(struct sock *sk, long timeout)
>         peer = sock->peer;
>         rcu_read_unlock();
>
> -       ovpn_peer_del(sock->peer, OVPN_DEL_PEER_REASON_TRANSPORT_DISCONNECT);
> +       ovpn_peer_del(peer, OVPN_DEL_PEER_REASON_TRANSPORT_DISCONNECT);
>         peer->tcp.sk_cb.prot->close(sk, timeout);
>         ovpn_peer_put(peer);
>  }

I do not see how rcu_read_lock() can protect sock->peer changes.

I think we need to be more careful, in the prior code which reads
sock->peer 3 times.

If RCU is used, we better use it properly.

rcu_read_lock();
sock = rcu_dereference_sk_user_data(sk);
if (!sock || !sock->peer || !ovpn_peer_hold(sock->peer)) {
        rcu_read_unlock();
        return;
}
peer = sock->peer;
rcu_read_unlock();

Re: [PATCH net 1/2] ovpn: tcp - use cached peer pointer in ovpn_tcp_close()

[David CARLIER]

Hi Eric,

On Tue, 12 May 2026 at 05:29, Eric Dumazet <edumazet@google.com> wrote:
>
> On Mon, May 11, 2026 at 9:20 PM David Carlier <devnexen@gmail.com> wrote:
> >
> > ovpn_tcp_close() loads the ovpn_socket via rcu_dereference_sk_user_data()
> > under rcu_read_lock(), takes a reference on sock->peer, caches the peer
> > pointer in a local, and drops the read lock. It then passes sock->peer
> > (rather than the cached local) to ovpn_peer_del(), re-dereferencing the
> > ovpn_socket after the RCU read section has ended.
> >
> > Unlike ovpn_tcp_sendmsg(), which uses the same "load under RCU, use
> > after unlock" pattern but is protected by lock_sock() held across the
> > function, ovpn_tcp_close() runs without the socket lock: inet_release()
> > invokes sk_prot->close() without taking lock_sock first.
> >
> > ovpn_socket_release() can therefore complete its kref_put -> detach ->
> > synchronize_rcu -> kfree(sock) sequence concurrently, in the window
> > after ovpn_tcp_close() drops rcu_read_lock() but before it dereferences
> > sock->peer. The synchronize_rcu() in ovpn_socket_release() protects
> > readers that use the dereferenced pointer inside the RCU read section,
> > not those that escape the pointer to a local and use it afterwards.
> >
> > A reproducer follows the pattern of commit 94560267d6c4 ("ovpn: tcp -
> > don't deref NULL sk_socket member after tcp_close()"): trigger a peer
> > removal (keepalive expiration or netlink OVPN_CMD_DEL_PEER) at the same
> > moment userspace closes the TCP fd. That commit fixed the detach-side
> > of the same race window; this one fixes the close-side at a different
> > victim.
> >
> > Use the already-loaded peer local, which is held by the
> > ovpn_peer_hold() taken under RCU and is the correct argument anyway.
> > The remaining lines in the function already use peer; switching this
> > call makes the function consistent and removes the dangling sock
> > dereference.
> >
> > Fixes: 11851cbd60ea ("ovpn: implement TCP transport")
> > Assisted-by: Claude:claude-opus-4-7
> > Signed-off-by: David Carlier <devnexen@gmail.com>
> > ---
> >  drivers/net/ovpn/tcp.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/net/ovpn/tcp.c b/drivers/net/ovpn/tcp.c
> > index 65054cc84be5..ed4782de141a 100644
> > --- a/drivers/net/ovpn/tcp.c
> > +++ b/drivers/net/ovpn/tcp.c
> > @@ -588,7 +588,7 @@ static void ovpn_tcp_close(struct sock *sk, long timeout)
> >         peer = sock->peer;
> >         rcu_read_unlock();
> >
> > -       ovpn_peer_del(sock->peer, OVPN_DEL_PEER_REASON_TRANSPORT_DISCONNECT);
> > +       ovpn_peer_del(peer, OVPN_DEL_PEER_REASON_TRANSPORT_DISCONNECT);
> >         peer->tcp.sk_cb.prot->close(sk, timeout);
> >         ovpn_peer_put(peer);
> >  }
>
> I do not see how rcu_read_lock() can protect sock->peer changes.
>
> I think we need to be more careful, in the prior code which reads
> sock->peer 3 times.
>
> If RCU is used, we better use it properly.
>
> rcu_read_lock();
> sock = rcu_dereference_sk_user_data(sk);
> if (!sock || !sock->peer || !ovpn_peer_hold(sock->peer)) {
>         rcu_read_unlock();
>         return;
> }
> peer = sock->peer;
> rcu_read_unlock();

You're right. sock->peer is only assigned once, in ovpn_socket_new()
  under lock_sock() before the ovpn_socket is even published via
  rcu_assign_sk_user_data(), and never touched again - which is why the
  three reads happen to be stable. But that's the kind of invariant the
  next person has to go dig up, so the pattern is doing nobody any
  favours.

  v2 tomorrow with sock->peer read once into the local up front, and
  all the subsequent uses going through that.

  Same multi-read pattern shows up in ovpn_tcp_recvmsg(),
  ovpn_tcp_sendmsg(), ovpn_tcp_data_ready() and ovpn_tcp_write_space()
  - happy to roll those into v2 as well, or punt to a follow-up,
  whichever you'd prefer.

  Thanks,
  David

Re: [PATCH net 1/2] ovpn: tcp - use cached peer pointer in ovpn_tcp_close()

[Antonio Quartulli]

Hi,

On 12/05/2026 06:56, David CARLIER wrote:
> Hi Eric,
> 
> On Tue, 12 May 2026 at 05:29, Eric Dumazet <edumazet@google.com> wrote:
>>
>> On Mon, May 11, 2026 at 9:20 PM David Carlier <devnexen@gmail.com> wrote:
>>>
>>> ovpn_tcp_close() loads the ovpn_socket via rcu_dereference_sk_user_data()
>>> under rcu_read_lock(), takes a reference on sock->peer, caches the peer
>>> pointer in a local, and drops the read lock. It then passes sock->peer
>>> (rather than the cached local) to ovpn_peer_del(), re-dereferencing the
>>> ovpn_socket after the RCU read section has ended.
>>>
>>> Unlike ovpn_tcp_sendmsg(), which uses the same "load under RCU, use
>>> after unlock" pattern but is protected by lock_sock() held across the
>>> function, ovpn_tcp_close() runs without the socket lock: inet_release()
>>> invokes sk_prot->close() without taking lock_sock first.
>>>
>>> ovpn_socket_release() can therefore complete its kref_put -> detach ->
>>> synchronize_rcu -> kfree(sock) sequence concurrently, in the window
>>> after ovpn_tcp_close() drops rcu_read_lock() but before it dereferences
>>> sock->peer. The synchronize_rcu() in ovpn_socket_release() protects
>>> readers that use the dereferenced pointer inside the RCU read section,
>>> not those that escape the pointer to a local and use it afterwards.
>>>
>>> A reproducer follows the pattern of commit 94560267d6c4 ("ovpn: tcp -
>>> don't deref NULL sk_socket member after tcp_close()"): trigger a peer
>>> removal (keepalive expiration or netlink OVPN_CMD_DEL_PEER) at the same
>>> moment userspace closes the TCP fd. That commit fixed the detach-side
>>> of the same race window; this one fixes the close-side at a different
>>> victim.
>>>
>>> Use the already-loaded peer local, which is held by the
>>> ovpn_peer_hold() taken under RCU and is the correct argument anyway.
>>> The remaining lines in the function already use peer; switching this
>>> call makes the function consistent and removes the dangling sock
>>> dereference.
>>>
>>> Fixes: 11851cbd60ea ("ovpn: implement TCP transport")
>>> Assisted-by: Claude:claude-opus-4-7
>>> Signed-off-by: David Carlier <devnexen@gmail.com>
>>> ---
>>>   drivers/net/ovpn/tcp.c | 2 +-
>>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/net/ovpn/tcp.c b/drivers/net/ovpn/tcp.c
>>> index 65054cc84be5..ed4782de141a 100644
>>> --- a/drivers/net/ovpn/tcp.c
>>> +++ b/drivers/net/ovpn/tcp.c
>>> @@ -588,7 +588,7 @@ static void ovpn_tcp_close(struct sock *sk, long timeout)
>>>          peer = sock->peer;
>>>          rcu_read_unlock();
>>>
>>> -       ovpn_peer_del(sock->peer, OVPN_DEL_PEER_REASON_TRANSPORT_DISCONNECT);
>>> +       ovpn_peer_del(peer, OVPN_DEL_PEER_REASON_TRANSPORT_DISCONNECT);
>>>          peer->tcp.sk_cb.prot->close(sk, timeout);
>>>          ovpn_peer_put(peer);
>>>   }
>>
>> I do not see how rcu_read_lock() can protect sock->peer changes.
>>
>> I think we need to be more careful, in the prior code which reads
>> sock->peer 3 times.
>>
>> If RCU is used, we better use it properly.
>>
>> rcu_read_lock();
>> sock = rcu_dereference_sk_user_data(sk);
>> if (!sock || !sock->peer || !ovpn_peer_hold(sock->peer)) {
>>          rcu_read_unlock();
>>          return;
>> }
>> peer = sock->peer;
>> rcu_read_unlock();
> 
> You're right. sock->peer is only assigned once, in ovpn_socket_new()
>    under lock_sock() before the ovpn_socket is even published via
>    rcu_assign_sk_user_data(), and never touched again - which is why the
>    three reads happen to be stable. But that's the kind of invariant the
>    next person has to go dig up, so the pattern is doing nobody any
>    favours.
> 
>    v2 tomorrow with sock->peer read once into the local up front, and
>    all the subsequent uses going through that.
> 
>    Same multi-read pattern shows up in ovpn_tcp_recvmsg(),
>    ovpn_tcp_sendmsg(), ovpn_tcp_data_ready() and ovpn_tcp_write_space()
>    - happy to roll those into v2 as well, or punt to a follow-up,
>    whichever you'd prefer.

I have to double check all the mentioned spots, however this sounds more 
like a larger refactoring for net-next that we should be carefully 
review, rather than a bugfix.


Regards,


-- 
Antonio Quartulli
OpenVPN Inc.

Re: [PATCH net 2/2] ovpn: respect peer refcount in CMD_NEW_PEER error path

[Antonio Quartulli]

Hi,

On 12/05/2026 06:19, David Carlier wrote:
> diff --git a/drivers/net/ovpn/netlink.c b/drivers/net/ovpn/netlink.c
> index 291e2e5bb450..4c66c1ec497e 100644
> --- a/drivers/net/ovpn/netlink.c
> +++ b/drivers/net/ovpn/netlink.c
> @@ -462,10 +462,12 @@ int ovpn_nl_peer_new_doit(struct sk_buff *skb, struct genl_info *info)
>   sock_release:
>   	ovpn_socket_release(peer);
>   peer_release:
> -	/* release right away because peer was not yet hashed, thus it is not
> -	 * used in any context
> +	/* For UDP, the peer is unreachable until added to the hashtables, so
> +	 * dropping the initial reference is enough. For TCP, the peer may be
> +	 * concurrently reachable via sk_user_data->peer until
> +	 * ovpn_socket_release() detaches; rely on the refcount.
>   	 */
> -	ovpn_peer_release(peer);
> +	ovpn_peer_put(peer);

Thanks for this patch!

Unless the CI Complains, I'm pulling this in my tree and staging it for 
the next PR to net.

Regards,

-- 
Antonio Quartulli
OpenVPN Inc.

Re: [PATCH net 1/2] ovpn: tcp - use cached peer pointer in ovpn_tcp_close()

[Antonio Quartulli]

Hi,

On 12/05/2026 06:56, David CARLIER wrote:
>    Same multi-read pattern shows up in ovpn_tcp_recvmsg(),
>    ovpn_tcp_sendmsg(), ovpn_tcp_data_ready() and ovpn_tcp_write_space()
>    - happy to roll those into v2 as well, or punt to a follow-up,
>    whichever you'd prefer.

@Eric, if you have no objection, I'd pick this patch up in my tree and 
let David follow with a new patch for net-next.

Regards,


-- 
Antonio Quartulli
OpenVPN Inc.

Re: [PATCH net 1/2] ovpn: tcp - use cached peer pointer in ovpn_tcp_close()

[Sabrina Dubroca]

2026-05-12, 15:55:39 +0200, Antonio Quartulli wrote:
> Hi,
> 
> On 12/05/2026 06:56, David CARLIER wrote:
> >    Same multi-read pattern shows up in ovpn_tcp_recvmsg(),
> >    ovpn_tcp_sendmsg(), ovpn_tcp_data_ready() and ovpn_tcp_write_space()
> >    - happy to roll those into v2 as well, or punt to a follow-up,
> >    whichever you'd prefer.
> 
> @Eric, if you have no objection, I'd pick this patch up in my tree and let
> David follow with a new patch for net-next.

But this patch is not fixing any problem either, right? Then just wait
until David sends the whole change at once?

And since the "rcu_dereference_sk_user_data + !sock || !sock->peer ||
!ovpn_peer_hold(sock->peer)" pattern is used multiple times, it would
be better to turn it into a helper (ovpn_tcp_get_peer()?). That way
the caller can't be tempted to play with sock->peer.

(also, please wait at least the usual 24 hours before applying)

-- 
Sabrina

Re: [PATCH net 1/2] ovpn: tcp - use cached peer pointer in ovpn_tcp_close()

[Antonio Quartulli]

On 12/05/2026 16:11, Sabrina Dubroca wrote:
> 2026-05-12, 15:55:39 +0200, Antonio Quartulli wrote:
>> Hi,
>>
>> On 12/05/2026 06:56, David CARLIER wrote:
>>>     Same multi-read pattern shows up in ovpn_tcp_recvmsg(),
>>>     ovpn_tcp_sendmsg(), ovpn_tcp_data_ready() and ovpn_tcp_write_space()
>>>     - happy to roll those into v2 as well, or punt to a follow-up,
>>>     whichever you'd prefer.
>>
>> @Eric, if you have no objection, I'd pick this patch up in my tree and let
>> David follow with a new patch for net-next.
> 
> But this patch is not fixing any problem either, right?

Mh, because the sock outlives the peer, so there is no risk in accessing 
sock->peer in this case, right?

 >  Then just wait until David sends the whole change at once?

Yap.

> 
> And since the "rcu_dereference_sk_user_data + !sock || !sock->peer ||
> !ovpn_peer_hold(sock->peer)" pattern is used multiple times, it would
> be better to turn it into a helper (ovpn_tcp_get_peer()?). That way
> the caller can't be tempted to play with sock->peer.
> 
> (also, please wait at least the usual 24 hours before applying)

ACK


Cheers,


-- 
Antonio Quartulli
OpenVPN Inc.

Re: [PATCH net 1/2] ovpn: tcp - use cached peer pointer in ovpn_tcp_close()

[Sabrina Dubroca]

2026-05-12, 16:17:39 +0200, Antonio Quartulli wrote:
> On 12/05/2026 16:11, Sabrina Dubroca wrote:
> > 2026-05-12, 15:55:39 +0200, Antonio Quartulli wrote:
> > > Hi,
> > > 
> > > On 12/05/2026 06:56, David CARLIER wrote:
> > > >     Same multi-read pattern shows up in ovpn_tcp_recvmsg(),
> > > >     ovpn_tcp_sendmsg(), ovpn_tcp_data_ready() and ovpn_tcp_write_space()
> > > >     - happy to roll those into v2 as well, or punt to a follow-up,
> > > >     whichever you'd prefer.
> > > 
> > > @Eric, if you have no objection, I'd pick this patch up in my tree and let
> > > David follow with a new patch for net-next.
> > 
> > But this patch is not fixing any problem either, right?
> 
> Mh, because the sock outlives the peer, so there is no risk in accessing
> sock->peer in this case, right?

I guess I got distracted by some of the discussion. I thought this was
only about "peer and sock->peer may differ", and not "sock may be gone
so sock->peer is not valid".

sock->peer can't change behind our backs, because, as David said:

    sock->peer is only assigned once, in ovpn_socket_new()


But the sock doesn't outlive the peer. ovpn_socket_release() does
ovpn_peer_put(), and frees the ovpn_socket immediately via
kfree(sock). So if:

   ovpn_tcp_close() starts, finds sk_user_data set and a peer, does peer_hold
   the peer gets deleted in parallel, ovpn_socket_release() frees the ovpn_socket
   ovpn_tcp_close() resumes and does ovpn_peer_del(sock->peer)

we can indeed hit a UAF on sock.


So this patch is needed as-is, sorry for my confusion earlier:

Reviewed-by: Sabrina Dubroca <sd@queasysnail.net>


The refactoring of all those peer accesses can be done in -next.

-- 
Sabrina

Re: [PATCH net 2/2] ovpn: respect peer refcount in CMD_NEW_PEER error path

[Sabrina Dubroca]

2026-05-12, 05:19:13 +0100, David Carlier wrote:
> diff --git a/drivers/net/ovpn/netlink.c b/drivers/net/ovpn/netlink.c
> index 291e2e5bb450..4c66c1ec497e 100644
> --- a/drivers/net/ovpn/netlink.c
> +++ b/drivers/net/ovpn/netlink.c
> @@ -462,10 +462,12 @@ int ovpn_nl_peer_new_doit(struct sk_buff *skb, struct genl_info *info)
>  sock_release:
>  	ovpn_socket_release(peer);
>  peer_release:
> -	/* release right away because peer was not yet hashed, thus it is not
> -	 * used in any context
> +	/* For UDP, the peer is unreachable until added to the hashtables, so
> +	 * dropping the initial reference is enough. For TCP, the peer may be
> +	 * concurrently reachable via sk_user_data->peer until
> +	 * ovpn_socket_release() detaches; rely on the refcount.
>  	 */
> -	ovpn_peer_release(peer);
> +	ovpn_peer_put(peer);
>  
>  	return ret;
>  }

nit: after this change, ovpn_peer_release() is only used within
peer.c, and can become static.

I think it'd be nicer to do that now with a v2, but if Antonio wants
to pick this patch up directly, the fix LGTM:

Reviewed-by: Sabrina Dubroca <sd@queasysnail.net>

-- 
Sabrina