[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20180823171732.GC14664@ziepe.ca>
Date: Thu, 23 Aug 2018 11:17:32 -0600
From: Jason Gunthorpe <jgg@...pe.ca>
To: Parav Pandit <parav@...lanox.com>
Cc: Eric Biggers <ebiggers@...nel.org>,
Doug Ledford <dledford@...hat.com>,
"linux-rdma@...r.kernel.org" <linux-rdma@...r.kernel.org>,
"dasaratharaman.chandramouli@...el.com"
<dasaratharaman.chandramouli@...el.com>,
Leon Romanovsky <leonro@...lanox.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Mark Bloch <markb@...lanox.com>,
Moni Shoua <monis@...lanox.com>,
"syzkaller-bugs@...glegroups.com" <syzkaller-bugs@...glegroups.com>,
syzbot <syzbot+29ee8f76017ce6cf03da@...kaller.appspotmail.com>
Subject: Re: [RDMA bug] KASAN: use-after-free Read in __list_del_entry_valid
(4)
On Thu, Aug 23, 2018 at 04:39:29PM +0000, Parav Pandit wrote:
>
>
> > From: Jason Gunthorpe <jgg@...pe.ca>
> > Sent: Thursday, August 23, 2018 9:55 AM
> > To: Eric Biggers <ebiggers@...nel.org>
> > Cc: Doug Ledford <dledford@...hat.com>; linux-rdma@...r.kernel.org;
> > dasaratharaman.chandramouli@...el.com; Leon Romanovsky
> > <leonro@...lanox.com>; linux-kernel@...r.kernel.org; Mark Bloch
> > <markb@...lanox.com>; Moni Shoua <monis@...lanox.com>; Parav Pandit
> > <parav@...lanox.com>; syzkaller-bugs@...glegroups.com; syzbot
> > <syzbot+29ee8f76017ce6cf03da@...kaller.appspotmail.com>
> > Subject: Re: [RDMA bug] KASAN: use-after-free Read in __list_del_entry_valid
> > (4)
> >
> > On Wed, Aug 22, 2018 at 11:16:31PM -0700, Eric Biggers wrote:
> > > Hello RDMA / InfiniBand maintainers,
> > >
> > > This is an RDMA bug and it still occurs on Linus' tree as of today
> > > (commit 815f0ddb346c1960).
> > >
> > > I've also simplified the reproducer for it; see below after the original report.
> > > Apparently it involves a race between RDMA_USER_CM_CMD_RESOLVE_IP
> > and
> > > RDMA_USER_CM_CMD_LISTEN.
> >
> > That is an amazing reproducer!
> >
> > I have a feeling this is the same cause as all the other syzkaller bugs in this code:
> > lack of any sane locking at all :\
> >
> > We've talked about chucking a big lock around this whole thing, but nobody has
> > done it yet.. It isn't so simple.
> >
>
> I had some code in which reduces three locks (handler_lock,
> qp_mutex, id_lock) to single mutex to protect the cm_id and protects
> every exported symbol of rdmacm which works on cm_id. But not ready
> enough to post it as patch yet. Lot of tests required before I get
> there and some refactor too before that.
That does sound promising..
Jason
Powered by blists - more mailing lists