Messages in this thread | | | Date | Thu, 26 Oct 2023 08:41:08 -0300 | From | Jason Gunthorpe <> | 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@ziepe.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@syzkaller.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
| |