[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CACT4Y+ab1q7fON3rkj+FHODPQXDGyP5c0tJt7gbrpmsAAYRb1g@mail.gmail.com>
Date: Mon, 29 Jun 2020 16:42:08 +0200
From: Dmitry Vyukov <dvyukov@...gle.com>
To: Jason Gunthorpe <jgg@...pe.ca>,
syzkaller <syzkaller@...glegroups.com>
Cc: Hillf Danton <hdanton@...a.com>,
syzbot <syzbot+a929647172775e335941@...kaller.appspotmail.com>,
chuck.lever@...cle.com, Doug Ledford <dledford@...hat.com>,
Leon Romanovsky <leon@...nel.org>,
LKML <linux-kernel@...r.kernel.org>,
RDMA mailing list <linux-rdma@...r.kernel.org>,
parav@...lanox.com, Markus Elfring <Markus.Elfring@....de>,
syzkaller-bugs <syzkaller-bugs@...glegroups.com>
Subject: Re: KASAN: use-after-free Read in addr_handler (2)
On Sun, Jun 28, 2020 at 12:25 AM Jason Gunthorpe <jgg@...pe.ca> wrote:
>
> On Sat, Jun 27, 2020 at 09:02:05PM +0800, Hillf Danton wrote:
> > > So, to hit this syzkaller one of these must have happened:
> > > 1) rdma_addr_cancel() didn't work and the process_one_work() is still
> > > runnable/running
> >
> > What syzbot reported indicates that the kworker did survive not only
> > canceling work but the handler_mutex, despite it's a sync cancel that
> > waits for the work to complete.
>
> The syzbot report doesn't confirm that the cancel work was actaully
> called.
>
> The most likely situation is that it was skipped because of the state
> mangling the patch fixes..
>
> > > 2) The state changed away from RDMA_CM_ADDR_QUERY without doing
> > > rdma_addr_cancel()
> >
> > The cancel does cover the query state in the reported case, and have
> > difficult time working out what's in the patch below preventing the
> > work from going across the line the sync cancel draws. That's the
> > question we can revisit once there is a reproducer available.
>
> rdma-cm never seems to get reproducers from syzkaller
+syzkaller mailing list
Hi Jason,
Wonder if there is some systematic issue. Let me double check.
Powered by blists - more mailing lists