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

[Michal Luczaj <mhal@rbox.co>]

On 10/7/26 02:27, netdev-bot+sashiko@kernel.org 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.

> [ ... ]
> 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.

> 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.

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