[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <VI1PR0501MB22714BE9A34FA333671A0623D1370@VI1PR0501MB2271.eurprd05.prod.outlook.com>
Date: Thu, 23 Aug 2018 16:39:29 +0000
From: Parav Pandit <parav@...lanox.com>
To: Jason Gunthorpe <jgg@...pe.ca>, Eric Biggers <ebiggers@...nel.org>
CC: 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)
> -----Original Message-----
> 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.
> Jason
Powered by blists - more mailing lists