Re: [PATCH net v4] vsock: treat TCP_CLOSING as once-established

[Stefano Garzarella]

On Wed, Oct 07, 2026 at 11:24:32AM +0200, Michal Luczaj wrote:
> On 10/7/26 02:27, netdev-bot+sashiko@xxxxxxxxxx wrote:
> > [Severity: High]
> > Can vsock_connect() still reset a socket that is already linked in
> > vsock_connected_table? This check only covers TCP_ESTABLISHED and
> > TCP_CLOSING. At least two transports move an established socket that is
> > already in the table straight to TCP_CLOSE, and neither one unlinks it.
> >
> > net/vmw_vsock/virtio_transport.c:virtio_vsock_reset_sock() {
> > 	sk->sk_state = TCP_CLOSE;
> > 	sk->sk_err = ECONNRESET;
> > 	sk_error_report(sk);
> > }
> >
> > virtio_vsock_event_handle() calls this for every connected socket on
> > VIRTIO_VSOCK_EVENT_TRANSPORT_RESET. It does not take lock_sock().
> >
> > net/vmw_vsock/vmci_transport.c:vmci_transport_handle_detach() {
> > 	...
> > 			sk->sk_state = TCP_CLOSE;
> > 		}
> > 		sk->sk_state_change(sk);
> > 	...
> > }
>
> Right, that's a known issue[1], to be handled separately.

Agree!

> > [ ... ]
> > sk_state does not seem to track table membership reliably. Would it be
> > more robust to check sock->state == SS_CONNECTED instead (the transports
> > set it together with vsock_insert_connected()),
>
> vsock_shutdown() complicates this. It can flip SS_CONNECTED to
> SS_DISCONNECTING.

Yeah, I'd avoid to use sock->state for what we are going to fix.

> > or to check membership in
> > connected_table directly? That check would have to guard both the
> > signal/timeout reset inside the loop and the sock_error() reset after the
> > loop.
>
> Lack of membership check for connected_table is not the root cause of the
> issue. But, sure, we can discuss adding it as a sanity check.

Agree also on this!

Thanks,
Stefano

> [1]: https://lore.kernel.org/netdev/arpBYXWb9pohx-8v@sgarzare-redhat/