[<prev] [next>] [day] [month] [year] [list]
Message-ID: <20231026114108.GS691768@ziepe.ca>
Date: Thu, 26 Oct 2023 08:41:08 -0300
From: Jason Gunthorpe <jgg@...pe.ca>
To: Hillf Danton <hdanton@...a.com>
Cc: syzbot <syzbot+45f6cae2ca8c1f71e529@...kaller.appspotmail.com>,
iommu@...ts.linux.dev, linux-kernel@...r.kernel.org,
robin.murphy@....com, syzkaller-bugs@...glegroups.com,
will@...nel.org
Subject: Re: [syzbot] [iommu?] KASAN: slab-use-after-free Read in
iommufd_ioas_iova_ranges
On Thu, Oct 26, 2023 at 07:05:02PM +0800, Hillf Danton wrote:
> On Wed, 25 Oct 2023 15:32:20 -0300 Jason Gunthorpe <jgg@...pe.ca>
> > On Wed, Oct 25, 2023 at 06:11:01AM -0700, syzbot wrote:
> > > Hello,
> > >
> > > syzbot found the following issue on:
> > >
> > > HEAD commit: c3200081020d Merge tag 'block-6.6-2023-10-20' of git://git..
> > > git tree: upstream
> > > console output: https://syzkaller.appspot.com/x/log.txt?x=15013471680000
> > > kernel config: https://syzkaller.appspot.com/x/.config?x=849fe52ba7c6d78a
> > > dashboard link: https://syzkaller.appspot.com/bug?extid=45f6cae2ca8c1f71e529
> > > compiler: Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40
> > >
> > > Unfortunately, I don't have any reproducer for this issue yet.
> > >
> > > Downloadable assets:
> > > disk image: https://storage.googleapis.com/syzbot-assets/caa5c1eed3ec/disk-c3200081.raw.xz
> > > vmlinux: https://storage.googleapis.com/syzbot-assets/7990a3a9f71e/vmlinux-c3200081.xz
> > > kernel image: https://storage.googleapis.com/syzbot-assets/015551ac9acc/bzImage-c3200081.xz
> > >
> > > IMPORTANT: if you fix the issue, please add the following tag to the commit:
> > > Reported-by: syzbot+45f6cae2ca8c1f71e529@...kaller.appspotmail.com
> > >
> > > ==================================================================
> > > BUG: KASAN: slab-use-after-free in __up_read+0xb3/0x690 kernel/locking/rwsem.c:1342
> > > Read of size 8 at addr ffff8880283c9068 by task syz-executor.2/30372
> >
> > Oh *ugh* I knew about this limitation once and forgot about it
> > apparently.
> >
> > CPU 0 CPU1
> > down_read()
> > up_read()
> > down_write()
> > up_write()
> > kfree()
> > [..]
> > tail portion of up_read()
> >
> > I suppose the rwsem should be turned into a refcount and completion
>
> The line [1] syzbot caught is before preempt is disabled,
So? It is SMP.
> so no lock is released yet, and the report is a simple uaf with
> nothing to do with down_write().
down_write() is one of the concurrent paths toward kfree.
tmp = atomic_long_add_return_release(-RWSEM_READER_BIAS, &sem->count);
^^^^ This allows the down_write to proceed to kfree
DEBUG_RWSEMS_WARN_ON(tmp < 0, sem);
if (unlikely((tmp & (RWSEM_LOCK_MASK|RWSEM_FLAG_WAITERS)) ==
RWSEM_FLAG_WAITERS)) {
clear_nonspinnable(sem);
rwsem_wake(sem);
}
And so if we are unlucky we can UAF someplace in this latter part.
Actually, this is a problem but it is not this problem since the sybot
traces don't show it going down the down_write side
I guess this is still just problems with the iommufd_object_remove,
since put is ordered
refcount_dec(&obj->users);
up_read(&obj->destroy_rwsem);
And remove doesn't touch the destroy_rwsem so it simple UAFs anywhere
in up_read and that matches the syzcaller trace of concurrent destroy
Jason
Powered by blists - more mailing lists