On 10/7/26 02:27, [email protected] 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/
