2026-02-02, 14:33:47 +0100, Antonio Quartulli wrote:
> This patch is actually fixing the same issue reported here:
>
> https://lore.kernel.org/netdev/[email protected]/
So it would be nice to add a
Link: <url>
tag just above the sign-off/fixes tag (to the netdev post or to the
debian bugtracker), and there could also be a Reported-by tag (you may
want to check with the reporter if they agree, but the debian
bugtracker publicly lists the name and email so I don't see why not).
> Cheers,
>
> On 02/02/2026 14:23, Ralf Lici wrote:
> > Currently, when a connected peer expires (no packets received within the
> > keepalive interval), we remove the peer and notify userspace of the
> > deletion. We then insert the peer in the release list and proceed to
> > detach and release the socket and the peer. This can be problematic with
> > TCP because, as soon as we send the notification, openvpn will close the
> > peer's socket and if ovpn_tcp_close is invoked before
> > ovpn_tcp_socket_detach we incurr in a NULL pointer dereference when
> > trying to access sk->sk_socket.
> >
> > Enforce correct ordering by calling ovpn_sock_release before invoking
> > the original socket close callback. This avoids potential race
> > conditions and guarantees that we completely detach from the socket once
> > userspace issues the close command.
The comment for ovpn_sock_release says:
* This function is expected to be invoked exactly once per peer
But it seems in this case we won't be obeying this assumption? Once
from ovpn_tcp_close, and again from unlock_ovpn in the timeout
handler?
IIRC this "invoked exactly once" was the condition that made
rcu_replace_pointer(peer->sock, NULL, true);
valid, but what will prevent both sides from seeing peer->sock != NULL
now?
(not really related, but maybe unlock_ovpn should be using
llist_for_each_entry_safe since the current peer might go away before
we grab the next list item?)
--
Sabrina
_______________________________________________
Openvpn-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
