linux-kernel - Re: KASAN: use-after-free Read in ucma

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

Message-ID: <20200911170139.GU87483@ziepe.ca>
Date:   Fri, 11 Sep 2020 14:01:39 -0300
From:   Jason Gunthorpe <jgg@...pe.ca>
To:     Hillf Danton <hdanton@...a.com>
Cc:     syzbot <syzbot+cc6fc752b3819e082d0c@...kaller.appspotmail.com>,
        dledford@...hat.com, leon@...nel.org, linux-kernel@...r.kernel.org,
        linux-rdma@...r.kernel.org, syzkaller-bugs@...glegroups.com
Subject: Re: KASAN: use-after-free Read in ucma_close (2)

On Fri, Sep 11, 2020 at 11:20:17PM +0800, Hillf Danton wrote:
> 
> On Fri, 11 Sep 2020 08:57:50 -0300 Jason Gunthorpe wrote:
> > On Fri, Sep 11, 2020 at 12:16:40PM +0800, Hillf Danton wrote:
> > > Detect race destroying ctx in order to avoid UAF.
> > > 
> > > +++ b/drivers/infiniband/core/ucma.c
> > > @@ -625,6 +625,10 @@ static ssize_t ucma_destroy_id(struct uc
> > >  		return PTR_ERR(ctx);
> > >  
> > >  	mutex_lock(&ctx->file->mut);
> > > +	if (ctx->destroying == 1) {
> > > +		mutex_unlock(&ctx->file->mut);
> > > +		return -ENXIO;
> > > +	}
> > >  	ctx->destroying = 1;
> > >  	mutex_unlock(&ctx->file->mut);
> > >  
> > > @@ -1826,6 +1830,8 @@ static int ucma_close(struct inode *inod
> > >  
> > >  	mutex_lock(&file->mut);
> > >  	list_for_each_entry_safe(ctx, tmp, &file->ctx_list, list) {
> > > +		if (ctx->destroying == 1)
> > > +			continue;
> > >  		ctx->destroying = 1;
> > >  		mutex_unlock(&file->mut);
> > >  
> > 
> > ucma_destroy_id() is called from write() and ucma_close is release(),
> > so there is no way these can race?
> 
> Sound good but what's reported is uaf in the close path, which is
> impossible without another thread releasing the ctx a step ahead
> the closer.
> Can we call it a race if that's true?

Migrate is the cause, very tricky:

		CPU0                      CPU1
	ucma_destroy_id()
				  ucma_migrate_id()
				       ucma_get_ctx()
	xa_lock()
	 _ucma_find_context()
	 xa_erase()
				       xa_lock()
					ctx->file = new_file
					list_move()
				       xa_unlock()
				      ucma_put_ctx
				   ucma_close()
				      _destroy_id()

	_destroy_id()
	  wait_for_completion()
	  // boom


ie the destrory_id() on the initial FD captures the ctx right before
migrate moves it, then the new FD closes calling destroy while the
other destroy is still running.

Sigh, I will rewrite migrate too..

Jason