netdev - Re: [PATCH resend] vsock/virtio: avoid potential deadlock when vsock device remove

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Thu, 12 Aug 2021 10:59:48 -0700
From:   Jakub Kicinski <kuba@...nel.org>
To:     Stefano Garzarella <sgarzare@...hat.com>
Cc:     "Longpeng(Mike)" <longpeng2@...wei.com>, kvm@...r.kernel.org,
        virtualization@...ts.linux-foundation.org, netdev@...r.kernel.org,
        arei.gonglei@...wei.com, linux-kernel@...r.kernel.org,
        Stefan Hajnoczi <stefanha@...hat.com>,
        "David S. Miller" <davem@...emloft.net>
Subject: Re: [PATCH resend] vsock/virtio: avoid potential deadlock when
 vsock device remove

On Thu, 12 Aug 2021 10:03:32 +0200 Stefano Garzarella wrote:
> On Thu, Aug 12, 2021 at 01:30:56PM +0800, Longpeng(Mike) wrote:
> >There's a potential deadlock case when remove the vsock device or
> >process the RESET event:
> >
> >  vsock_for_each_connected_socket:
> >      spin_lock_bh(&vsock_table_lock) ----------- (1)
> >      ...
> >          virtio_vsock_reset_sock:
> >              lock_sock(sk) --------------------- (2)
> >      ...
> >      spin_unlock_bh(&vsock_table_lock)
> >
> >lock_sock() may do initiative schedule when the 'sk' is owned by
> >other thread at the same time, we would receivce a warning message
> >that "scheduling while atomic".
> >
> >Even worse, if the next task (selected by the scheduler) try to
> >release a 'sk', it need to request vsock_table_lock and the deadlock
> >occur, cause the system into softlockup state.
> >  Call trace:
> >   queued_spin_lock_slowpath
> >   vsock_remove_bound
> >   vsock_remove_sock
> >   virtio_transport_release
> >   __vsock_release
> >   vsock_release
> >   __sock_release
> >   sock_close
> >   __fput
> >   ____fput
> >
> >So we should not require sk_lock in this case, just like the behavior
> >in vhost_vsock or vmci.  
>
> We should add:
> Fixes: 0ea9e1d3a9e3 ("VSOCK: Introduce virtio_transport.ko")

Added.

> Reviewed-by: Stefano Garzarella <sgarzare@...hat.com>

And applied, thanks!