[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <20200227.120423.2054408641031093845.davem@davemloft.net>
Date: Thu, 27 Feb 2020 12:04:23 -0800 (PST)
From: David Miller <davem@...emloft.net>
To: sgarzare@...hat.com
Cc: decui@...rosoft.com, hdanton@...a.com,
virtualization@...ts.linux-foundation.org, kys@...rosoft.com,
kvm@...r.kernel.org, sthemmin@...rosoft.com,
syzbot+731710996d79d0d58fbc@...kaller.appspotmail.com,
netdev@...r.kernel.org, sashal@...nel.org, sunilmut@...rosoft.com,
linux-kernel@...r.kernel.org, linux-hyperv@...r.kernel.org,
kuba@...nel.org, haiyangz@...rosoft.com, stefanha@...hat.com,
jhansen@...are.com
Subject: Re: [PATCH net] vsock: fix potential deadlock in
transport->release()
From: Stefano Garzarella <sgarzare@...hat.com>
Date: Wed, 26 Feb 2020 11:58:18 +0100
> Some transports (hyperv, virtio) acquire the sock lock during the
> .release() callback.
>
> In the vsock_stream_connect() we call vsock_assign_transport(); if
> the socket was previously assigned to another transport, the
> vsk->transport->release() is called, but the sock lock is already
> held in the vsock_stream_connect(), causing a deadlock reported by
> syzbot:
...
> To avoid this issue, this patch remove the lock acquiring in the
> .release() callback of hyperv and virtio transports, and it holds
> the lock when we call vsk->transport->release() in the vsock core.
>
> Reported-by: syzbot+731710996d79d0d58fbc@...kaller.appspotmail.com
> Fixes: 408624af4c89 ("vsock: use local transport when it is loaded")
> Signed-off-by: Stefano Garzarella <sgarzare@...hat.com>
Applied, thank you.
Powered by blists - more mailing lists