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

[Stefano Garzarella <sgarzare@redhat.com>]

On Wed, Oct 07, 2026 at 11:24:32AM +0200, Michal Luczaj wrote:
>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.

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