Re: possible deadlock in virtio_transport_release (vsock_register_mutex vs sk_lock)

[Stefano Garzarella]

On Thu, 9 Apr 2026 at 11:06, weibo Zhang <weibozhang2050@xxxxxxxxx> wrote:
>
> Hi,
>
> I am reporting a possible circular locking dependency (AB-BA deadlock) in the
>
> vsock subsystem between vsock_register_mutex and sk_lock-AF_VSOCK, found by
>
> syzkaller-based kernel fuzzing on Linux 6.12.47.
>
> The deadlock is detected by lockdep and involves two lock ordering paths:
>
> Path #1 (bind path): sk_lock → vsock_register_mutex
>
> vsock_bind() → lock_sock(sk) → __vsock_bind() → vsock_find_cid()
>
> → vsock_registered_transport_cid() → mutex_lock(&vsock_register_mutex)
>
> Path #2 (connect + transport reassignment): vsock_register_mutex → sk_lock
>
> vsock_connect() → vsock_assign_transport()
>
> → mutex_lock(&vsock_register_mutex) [line 469, af_vsock.c]
>
> → old transport->release(vsk) [line 502, af_vsock.c]
>
> → virtio_transport_release()
>
> → virtio_transport_close()
>
> → virtio_transport_wait_close()
>
> → lock_sock(sk) [line 1207, virtio_transport_common.c]
>
> The second path is triggered when a socket that already has a transport
>
> assigned (e.g., loopback from a previous CID_LOCAL connect) attempts to
>
> connect to a different CID (e.g., CID_HOST), causing vsock_assign_transport()
>
> to release the old transport while holding vsock_register_mutex.
>
>
> A possible fix would be to drop vsock_register_mutex before calling
>
> transport->release() in vsock_assign_transport(), or to avoid calling

Which is exactly what we did with
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f7c877e7535260cc7a21484c994e8ce7e8cb6780

This was released with v6.18 and backported on stable branches.

>
> lock_sock() from within the transport release path when called from
>
> vsock_assign_transport().
>
> This can be reproduced on:
>
> HEAD commit: Linux 6.12.47

v6.12.56 should contain the backport of that patch, can you test it
(or a newer version)?

Thanks,
Stefano