Hi Hangbin, I finaly got to the bottom of this - the issue was indeed in the VMCI driver. The patch is posted here:
https://lkml.org/lkml/2018/9/21/326 I used your reproduce.log to test the fix. Thanks for discovering this issue. Thanks, Jørgen ________________________________________ From: Hangbin Liu <liuhang...@gmail.com> Sent: Wednesday, June 13, 2018 3:44 AM To: Jorgen S. Hansen Cc: Stefan Hajnoczi; netdev@vger.kernel.org; David S. Miller Subject: Re: [PATCH net] VSOCK: check sk state before receive On Mon, Jun 04, 2018 at 04:02:39PM +0000, Jorgen S. Hansen wrote: > > > On May 30, 2018, at 11:17 AM, Stefan Hajnoczi <stefa...@redhat.com> wrote: > > > > On Sun, May 27, 2018 at 11:29:45PM +0800, Hangbin Liu wrote: > >> Hmm...Although I won't reproduce this bug with my reproducer after > >> apply my patch. I could still get a similiar issue with syzkaller sock > >> vnet test. > >> > >> It looks this patch is not complete. Here is the KASAN call trace with my > >> patch. > >> I can also reproduce it without my patch. > > > > Seems like a race between vmci_datagram_destroy_handle() and the > > delayed callback, vmci_transport_recv_dgram_cb(). > > > > I don't know the VMCI transport well so I'll leave this to Jorgen. > > Yes, it looks like we are calling the delayed callback after we return from > vmci_datagram_destroy_handle(). I’ll take a closer look at the VMCI side here > - the refcounting of VMCI datagram endpoints should guard against this, since > the delayed callback does a get on the datagram resource, so this could a > VMCI driver issue, and not a problem in the VMCI transport for AF_VSOCK. Hi Jorgen, Thanks for helping look at this. I'm happy to run test for you patch. Thanks Hangbin
