netdev - Re: [PATCH net] VSOCK: check sk state before receive

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <MWHPR05MB3376DF7EC1FEC4E9A4112F3BDA120@MWHPR05MB3376.namprd05.prod.outlook.com>
Date:   Fri, 21 Sep 2018 07:48:25 +0000
From:   "Jorgen S. Hansen" <jhansen@...are.com>
To:     Hangbin Liu <liuhangbin@...il.com>
CC:     Stefan Hajnoczi <stefanha@...hat.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "David S. Miller" <davem@...emloft.net>
Subject: Re: [PATCH net] VSOCK: check sk state before receive

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 <liuhangbin@...il.com>
Sent: Wednesday, June 13, 2018 3:44 AM
To: Jorgen S. Hansen
Cc: Stefan Hajnoczi; netdev@...r.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 <stefanha@...hat.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