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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CACT4Y+bSb8ck4C-Uc2E-2xP=W_r-2i3KUSnqfHr=Z7GB46+CAg@mail.gmail.com>
Date:   Thu, 16 Sep 2021 17:17:27 +0200
From:   Dmitry Vyukov <dvyukov@...gle.com>
To:     Jason Gunthorpe <jgg@...pe.ca>
Cc:     syzbot <syzbot+dc3dfba010d7671e05f5@...kaller.appspotmail.com>,
        dledford@...hat.com, leon@...nel.org, linux-kernel@...r.kernel.org,
        linux-rdma@...r.kernel.org, syzkaller-bugs@...glegroups.com,
        Aleksandr Nogikh <nogikh@...gle.com>
Subject: Re: [syzbot] KASAN: use-after-free Read in addr_handler (4)

On Thu, 16 Sept 2021 at 17:08, Jason Gunthorpe <jgg@...pe.ca> wrote:
>
> On Thu, Sep 16, 2021 at 04:55:16PM +0200, Dmitry Vyukov wrote:
>
> > > I noticed we also had 2 KCSAN reports that mention rdma_resolve_addr.
> > >
> > > On commit 1df0d896:
> > > ==================================================================
> > > BUG: KCSAN: data-race in addr_handler / cma_check_port
> > >
> > > write to 0xffff88809fa40a1c of 4 bytes by task 21 on cpu 1:
> > >  cma_comp_exch drivers/infiniband/core/cma.c:426 [inline]
> > >  addr_handler+0x9f/0x2b0 drivers/infiniband/core/cma.c:3141
> > >  process_one_req+0x22f/0x300 drivers/infiniband/core/addr.c:645
> > >  process_one_work+0x3e1/0x9a0 kernel/workqueue.c:2269
> > >  worker_thread+0x665/0xbe0 kernel/workqueue.c:2415
> > >  kthread+0x20d/0x230 kernel/kthread.c:291
> > >  ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:293
> > >
> > > read to 0xffff88809fa40a1c of 4 bytes by task 11997 on cpu 0:
> > >  cma_check_port+0xbd/0x700 drivers/infiniband/core/cma.c:3506
>
> This has since been fixed, cma_check_port() no longer reads state
>
> > > and on commit 5863cc79:
>
> I can't find this commit? Current rdma_resolve_addr should not trigger
> this KCSAN.
>
> > This does not immediately explain the use-after-free for me, but these
> > races suggest that everything is not protected by a single mutex and
> > that there may be some surprising interleavings.
> > E.g. rdma_resolve_addr checks status, and then conditionally executes
> > cma_bind_addr, but the status can change concurrently.
>
> It is true, they weren't, however I've fixed them all. These hits look
> like they all from before it got fixed up..

Then sorry for false leads.
The second commit was from https://github.com/google/ktsan.git kcsan
branch. I am not sure if it's still present or was rebased. But either
way it's even older than the first report on upstream (we used ktsan
tree before switched to upstream).

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ