From mboxrd@z Thu Jan  1 00:00:00 1970
From: Hangbin Liu <liuhangbin@gmail.com>
Subject: Re: [PATCH net] VSOCK: check sk state before receive
Date: Wed, 13 Jun 2018 09:44:02 +0800
Message-ID: <20180613014402.GU8958@leo.usersys.redhat.com>
References: <1527382936-4850-1-git-send-email-liuhangbin@gmail.com>
 <20180527152945.GQ8958@leo.usersys.redhat.com>
 <20180530091727.GF14623@stefanha-x1.localdomain>
 <E9BA11C2-0F15-4FFF-8E29-74640E82D046@vmware.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Cc: Stefan Hajnoczi <stefanha@redhat.com>,
        "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
        "David S. Miller" <davem@davemloft.net>
To: "Jorgen S. Hansen" <jhansen@vmware.com>
Return-path: <netdev-owner@vger.kernel.org>
Received: from mail-pf0-f196.google.com ([209.85.192.196]:34723 "EHLO
        mail-pf0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S932985AbeFMBoP (ORCPT
        <rfc822;netdev@vger.kernel.org>); Tue, 12 Jun 2018 21:44:15 -0400
Received: by mail-pf0-f196.google.com with SMTP id a63-v6so498229pfl.1
        for <netdev@vger.kernel.org>; Tue, 12 Jun 2018 18:44:15 -0700 (PDT)
Content-Disposition: inline
In-Reply-To: <E9BA11C2-0F15-4FFF-8E29-74640E82D046@vmware.com>
Sender: netdev-owner@vger.kernel.org
List-ID: <netdev.vger.kernel.org>

On Mon, Jun 04, 2018 at 04:02:39PM +0000, Jorgen S. Hansen wrote:
> 
> > On May 30, 2018, at 11:17 AM, Stefan Hajnoczi <stefanha@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