* [PATCH rc 0/2] iommufd syzkaller fixes @ 2023-06-19 18:24 Jason Gunthorpe 2023-06-19 18:24 ` [PATCH rc 1/2] iommufd: Do not access the area pointer after unlocking Jason Gunthorpe 2023-06-19 18:24 ` [PATCH rc 2/2] iommufd: Call iopt_area_contig_done() under the lock Jason Gunthorpe 0 siblings, 2 replies; 7+ messages in thread From: Jason Gunthorpe @ 2023-06-19 18:24 UTC (permalink / raw) To: iommu Cc: Kevin Tian, Lixiao Yang, Matthew Rosato, Nicolin Chen, syzbot+1ad12d16afca0e7d2dde, syzbot+6c8d756f238a75fc3eb8, Yi Liu Two syzkaller fixes, both the same botched locking of the area pointer during the unmap of IOVA being used by an access. Jason Gunthorpe (2): iommufd: Do not access the area pointer after unlocking iommufd: Call iopt_area_contig_done() under the lock drivers/iommu/iommufd/device.c | 2 +- drivers/iommu/iommufd/io_pagetable.c | 11 ++++++++--- 2 files changed, 9 insertions(+), 4 deletions(-) base-commit: 45a3e24f65e90a047bef86f927ebdc4c710edaa1 -- 2.40.1 ^ permalink raw reply [flat|nested] 7+ messages in thread
* [PATCH rc 1/2] iommufd: Do not access the area pointer after unlocking 2023-06-19 18:24 [PATCH rc 0/2] iommufd syzkaller fixes Jason Gunthorpe @ 2023-06-19 18:24 ` Jason Gunthorpe 2023-06-20 4:42 ` Nicolin Chen 2023-06-19 18:24 ` [PATCH rc 2/2] iommufd: Call iopt_area_contig_done() under the lock Jason Gunthorpe 1 sibling, 1 reply; 7+ messages in thread From: Jason Gunthorpe @ 2023-06-19 18:24 UTC (permalink / raw) To: iommu Cc: Kevin Tian, Lixiao Yang, Matthew Rosato, Nicolin Chen, syzbot+1ad12d16afca0e7d2dde, syzbot+6c8d756f238a75fc3eb8, Yi Liu A concurrent unmap can trigger freeing of the area pointers while we are generating an unmapping notification for accesses. syzkaller reports: BUG: KASAN: slab-use-after-free in iopt_unmap_iova_range+0x5ba/0x5f0 Read of size 4 at addr ffff888075996184 by task syz-executor.2/31160 CPU: 1 PID: 31160 Comm: syz-executor.2 Not tainted 6.4.0-rc5-syzkaller-00313-g4c605260bc60 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/25/2023 Call Trace: <TASK> dump_stack_lvl+0xd9/0x150 print_address_description.constprop.0+0x2c/0x3c0 kasan_report+0x11c/0x130 iopt_unmap_iova_range+0x5ba/0x5f0 iopt_unmap_all+0x27/0x50 iommufd_ioas_unmap+0x3d0/0x490 iommufd_fops_ioctl+0x317/0x4b0 __x64_sys_ioctl+0x197/0x210 do_syscall_64+0x39/0xb0 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7f0812c8c169 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 f1 19 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f0813914168 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007f0812dabf80 RCX: 00007f0812c8c169 RDX: 0000000020000100 RSI: 0000000000003b86 RDI: 0000000000000005 RBP: 00007f0812ce7ca1 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007f0812ecfb1f R14: 00007f0813914300 R15: 0000000000022000 </TASK> Allocated by task 31160: kasan_save_stack+0x22/0x40 kasan_set_track+0x25/0x30 __kasan_kmalloc+0xa2/0xb0 iopt_alloc_area_pages+0x94/0x560 iopt_map_user_pages+0x205/0x4e0 iommufd_ioas_map+0x329/0x5f0 iommufd_fops_ioctl+0x317/0x4b0 __x64_sys_ioctl+0x197/0x210 do_syscall_64+0x39/0xb0 entry_SYSCALL_64_after_hwframe+0x63/0xcd Freed by task 31161: kasan_save_stack+0x22/0x40 kasan_set_track+0x25/0x30 kasan_save_free_info+0x2e/0x40 ____kasan_slab_free+0x160/0x1c0 slab_free_freelist_hook+0x8b/0x1c0 __kmem_cache_free+0xaf/0x2d0 iopt_unmap_iova_range+0x288/0x5f0 iopt_unmap_all+0x27/0x50 iommufd_ioas_unmap+0x3d0/0x490 iommufd_fops_ioctl+0x317/0x4b0 __x64_sys_ioctl+0x197/0x210 do_syscall_64+0x39/0xb0 entry_SYSCALL_64_after_hwframe+0x63/0xcd The buggy address belongs to the object at ffff888075996100 which belongs to the cache kmalloc-cg-192 of size 192 The buggy address is located 132 bytes inside of freed 192-byte region [ffff888075996100, ffff8880759961c0) The buggy address belongs to the physical page: page:ffffea0001d66580 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x75996 memcg:ffff88801f1c2701 flags: 0xfff00000000200(slab|node=0|zone=1|lastcpupid=0x7ff) page_type: 0xffffffff() raw: 00fff00000000200 ffff88801244ddc0 dead000000000122 0000000000000000 raw: 0000000000000000 0000000080100010 00000001ffffffff ffff88801f1c2701 page dumped because: kasan: bad access detected page_owner tracks the page as allocated page last allocated via order 0, migratetype Unmovable, gfp_mask 0x112cc0(GFP_USER|__GFP_NOWARN|__GFP_NORETRY), pid 31157, tgid 31154 (syz-executor.0), ts 1984547323469, free_ts 1983933451331 post_alloc_hook+0x2db/0x350 get_page_from_freelist+0xf41/0x2c00 __alloc_pages+0x1cb/0x4a0 alloc_pages+0x1aa/0x270 allocate_slab+0x25f/0x390 ___slab_alloc+0xa91/0x1400 __slab_alloc.constprop.0+0x56/0xa0 __kmem_cache_alloc_node+0x136/0x320 kmalloc_trace+0x26/0xe0 iommufd_test+0x1328/0x2c20 iommufd_fops_ioctl+0x317/0x4b0 __x64_sys_ioctl+0x197/0x210 do_syscall_64+0x39/0xb0 entry_SYSCALL_64_after_hwframe+0x63/0xcd page last free stack trace: free_unref_page_prepare+0x62e/0xcb0 free_unref_page_list+0xe3/0xa70 release_pages+0xcd8/0x1380 tlb_batch_pages_flush+0xa8/0x1a0 tlb_finish_mmu+0x14b/0x7e0 exit_mmap+0x2b2/0x930 __mmput+0x128/0x4c0 mmput+0x60/0x70 do_exit+0x9b0/0x29b0 do_group_exit+0xd4/0x2a0 get_signal+0x2318/0x25b0 arch_do_signal_or_restart+0x79/0x5c0 exit_to_user_mode_prepare+0x11f/0x240 syscall_exit_to_user_mode+0x1d/0x50 do_syscall_64+0x46/0xb0 entry_SYSCALL_64_after_hwframe+0x63/0xcd Precompute what is needed to call the access function and do not check the area's num_accesses again as the pointer may not be valid anymore. Use a counter instead. Fixes: 51fe6141f0f6 ("iommufd: Data structure to provide IOVA to PFN mapping") Reported-by: syzbot+1ad12d16afca0e7d2dde@syzkaller.appspotmail.com Closes: https://lore.kernel.org/r/0000000000001d40fc05fe385332@google.com Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> --- drivers/iommu/iommufd/io_pagetable.c | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/drivers/iommu/iommufd/io_pagetable.c b/drivers/iommu/iommufd/io_pagetable.c index e0ae72b9e67f86..bab9b6464d18b8 100644 --- a/drivers/iommu/iommufd/io_pagetable.c +++ b/drivers/iommu/iommufd/io_pagetable.c @@ -458,6 +458,7 @@ static int iopt_unmap_iova_range(struct io_pagetable *iopt, unsigned long start, { struct iopt_area *area; unsigned long unmapped_bytes = 0; + unsigned int tries = 0; int rc = -ENOENT; /* @@ -490,13 +491,17 @@ static int iopt_unmap_iova_range(struct io_pagetable *iopt, unsigned long start, * without the pages->mutex. */ if (area->num_accesses) { + size_t length = iopt_area_length(area); + start = area_first; area->prevent_access = true; up_write(&iopt->iova_rwsem); up_read(&iopt->domains_rwsem); - iommufd_access_notify_unmap(iopt, area_first, - iopt_area_length(area)); - if (WARN_ON(READ_ONCE(area->num_accesses))) + + iommufd_access_notify_unmap(iopt, area_first, length); + /* Something is not responding to unmap requests. */ + tries++; + if (WARN_ON(tries > 1000)) return -EDEADLOCK; goto again; } -- 2.40.1 ^ permalink raw reply related [flat|nested] 7+ messages in thread
* Re: [PATCH rc 1/2] iommufd: Do not access the area pointer after unlocking 2023-06-19 18:24 ` [PATCH rc 1/2] iommufd: Do not access the area pointer after unlocking Jason Gunthorpe @ 2023-06-20 4:42 ` Nicolin Chen 2023-06-20 5:30 ` Tian, Kevin 0 siblings, 1 reply; 7+ messages in thread From: Nicolin Chen @ 2023-06-20 4:42 UTC (permalink / raw) To: Jason Gunthorpe Cc: iommu, Kevin Tian, Lixiao Yang, Matthew Rosato, syzbot+1ad12d16afca0e7d2dde, syzbot+6c8d756f238a75fc3eb8, Yi Liu On Mon, Jun 19, 2023 at 03:24:58PM -0300, Jason Gunthorpe wrote: > Precompute what is needed to call the access function and do not check the > area's num_accesses again as the pointer may not be valid anymore. Use a > counter instead. > @@ -458,6 +458,7 @@ static int iopt_unmap_iova_range(struct io_pagetable *iopt, unsigned long start, > { > struct iopt_area *area; > unsigned long unmapped_bytes = 0; > + unsigned int tries = 0; > int rc = -ENOENT; > > /* > @@ -490,13 +491,17 @@ static int iopt_unmap_iova_range(struct io_pagetable *iopt, unsigned long start, > * without the pages->mutex. > */ > if (area->num_accesses) { > + size_t length = iopt_area_length(area); > + > start = area_first; > area->prevent_access = true; > up_write(&iopt->iova_rwsem); > up_read(&iopt->domains_rwsem); > - iommufd_access_notify_unmap(iopt, area_first, > - iopt_area_length(area)); > - if (WARN_ON(READ_ONCE(area->num_accesses))) > + > + iommufd_access_notify_unmap(iopt, area_first, length); > + /* Something is not responding to unmap requests. */ > + tries++; > + if (WARN_ON(tries > 1000)) Hmm, just trying to understand this piece here... IIUIC, the iommufd_access_notify_unmap() notifies the vfio device to do a vfio_unpin_pages() that would do a "num_accesses--;". But how does the counter work instead? And why 1000? Btw, there seems to be a small typo in the comments above this piece of code, though it's not in this patch: s/iovam_rwsem/iova_rwsem Thanks Nicolin ^ permalink raw reply [flat|nested] 7+ messages in thread
* RE: [PATCH rc 1/2] iommufd: Do not access the area pointer after unlocking 2023-06-20 4:42 ` Nicolin Chen @ 2023-06-20 5:30 ` Tian, Kevin 2023-06-20 12:36 ` Jason Gunthorpe 0 siblings, 1 reply; 7+ messages in thread From: Tian, Kevin @ 2023-06-20 5:30 UTC (permalink / raw) To: Nicolin Chen, Jason Gunthorpe Cc: iommu@lists.linux.dev, Lixiao Yang, Matthew Rosato, syzbot+1ad12d16afca0e7d2dde@syzkaller.appspotmail.com, syzbot+6c8d756f238a75fc3eb8@syzkaller.appspotmail.com, Liu, Yi L > From: Nicolin Chen <nicolinc@nvidia.com> > Sent: Tuesday, June 20, 2023 12:42 PM > > On Mon, Jun 19, 2023 at 03:24:58PM -0300, Jason Gunthorpe wrote: > > > Precompute what is needed to call the access function and do not check the > > area's num_accesses again as the pointer may not be valid anymore. Use a > > counter instead. > > > @@ -458,6 +458,7 @@ static int iopt_unmap_iova_range(struct > io_pagetable *iopt, unsigned long start, > > { > > struct iopt_area *area; > > unsigned long unmapped_bytes = 0; > > + unsigned int tries = 0; > > int rc = -ENOENT; > > > > /* > > @@ -490,13 +491,17 @@ static int iopt_unmap_iova_range(struct > io_pagetable *iopt, unsigned long start, > > * without the pages->mutex. > > */ > > if (area->num_accesses) { > > + size_t length = iopt_area_length(area); > > + > > start = area_first; > > area->prevent_access = true; > > up_write(&iopt->iova_rwsem); > > up_read(&iopt->domains_rwsem); > > - iommufd_access_notify_unmap(iopt, area_first, > > - iopt_area_length(area)); > > - if (WARN_ON(READ_ONCE(area->num_accesses))) > > + > > + iommufd_access_notify_unmap(iopt, area_first, > length); > > + /* Something is not responding to unmap requests. > */ > > + tries++; > > + if (WARN_ON(tries > 1000)) > > Hmm, just trying to understand this piece here... > > IIUIC, the iommufd_access_notify_unmap() notifies the vfio device > to do a vfio_unpin_pages() that would do a "num_accesses--;". But > how does the counter work instead? And why 1000? > this looks incorrect. If the unmapped range covers more than 1000 areas and each area is attached by an access, this logic implies that an error will be returned after the first 1000 areas are unmapped. IMHO here we want to record the last notified area and compare it in retry, e.g.: struct iopt_area *last_notify_area = NULL; again: down_read(&iopt->domains_rwsem); down_write(&iopt->iova_rwsem); while (...) { ... if (area->num_accesses) { size_t length = iopt_area_length(area); /* Something is not responding to previous unmap request */ if (WARN_ON(area == last_notify_area)) { rc = -EDEADLOCK; goto out_unlock_iova; } start = area_first; area->prevent_access = true; up_write(&iopt->iova_rwsem); up_read(&iopt->domains_rwsem); /* the pointer is used only for comparison hence safe to update w/o lock */ last_notify_area = area; iommufd_access_notify_unmap(iopt, area_first, length); goto again; } ... } ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH rc 1/2] iommufd: Do not access the area pointer after unlocking 2023-06-20 5:30 ` Tian, Kevin @ 2023-06-20 12:36 ` Jason Gunthorpe 0 siblings, 0 replies; 7+ messages in thread From: Jason Gunthorpe @ 2023-06-20 12:36 UTC (permalink / raw) To: Tian, Kevin Cc: Nicolin Chen, iommu@lists.linux.dev, Lixiao Yang, Matthew Rosato, syzbot+1ad12d16afca0e7d2dde@syzkaller.appspotmail.com, syzbot+6c8d756f238a75fc3eb8@syzkaller.appspotmail.com, Liu, Yi L On Tue, Jun 20, 2023 at 05:30:39AM +0000, Tian, Kevin wrote: > this looks incorrect. If the unmapped range covers more than 1000 areas > and each area is attached by an access, this logic implies that an error will > be returned after the first 1000 areas are unmapped. Yes, that makes sense > IMHO here we want to record the last notified area and compare it in > retry, e.g.: > > struct iopt_area *last_notify_area = NULL; We can't use the area pointer, but we can keep track of the IOVA and reset tries as it progresses. Thanks, Jason ^ permalink raw reply [flat|nested] 7+ messages in thread
* [PATCH rc 2/2] iommufd: Call iopt_area_contig_done() under the lock 2023-06-19 18:24 [PATCH rc 0/2] iommufd syzkaller fixes Jason Gunthorpe 2023-06-19 18:24 ` [PATCH rc 1/2] iommufd: Do not access the area pointer after unlocking Jason Gunthorpe @ 2023-06-19 18:24 ` Jason Gunthorpe 2023-06-20 5:34 ` Tian, Kevin 1 sibling, 1 reply; 7+ messages in thread From: Jason Gunthorpe @ 2023-06-19 18:24 UTC (permalink / raw) To: iommu Cc: Kevin Tian, Lixiao Yang, Matthew Rosato, Nicolin Chen, syzbot+1ad12d16afca0e7d2dde, syzbot+6c8d756f238a75fc3eb8, Yi Liu The iter internally holds a pointer to the area and iopt_area_contig_done() will dereference it. The pointer is not valid outside the iova_rwsem. syzkaller reports: BUG: KASAN: slab-use-after-free in iommufd_access_unpin_pages+0x363/0x370 Read of size 8 at addr ffff888022286e20 by task syz-executor669/5771 CPU: 0 PID: 5771 Comm: syz-executor669 Not tainted 6.4.0-rc5-syzkaller-00313-g4c605260bc60 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/25/2023 Call Trace: <TASK> dump_stack_lvl+0xd9/0x150 print_address_description.constprop.0+0x2c/0x3c0 kasan_report+0x11c/0x130 iommufd_access_unpin_pages+0x363/0x370 iommufd_test_access_unmap+0x24b/0x390 iommufd_access_notify_unmap+0x24c/0x3a0 iopt_unmap_iova_range+0x4c4/0x5f0 iopt_unmap_all+0x27/0x50 iommufd_ioas_unmap+0x3d0/0x490 iommufd_fops_ioctl+0x317/0x4b0 __x64_sys_ioctl+0x197/0x210 do_syscall_64+0x39/0xb0 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7fec1dae3b19 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 11 15 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fec1da74308 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007fec1db6b438 RCX: 00007fec1dae3b19 RDX: 0000000020000100 RSI: 0000000000003b86 RDI: 0000000000000003 RBP: 00007fec1db6b430 R08: 00007fec1da74700 R09: 0000000000000000 R10: 00007fec1da74700 R11: 0000000000000246 R12: 00007fec1db6b43c R13: 00007fec1db39074 R14: 6d6f692f7665642f R15: 0000000000022000 </TASK> Allocated by task 5770: kasan_save_stack+0x22/0x40 kasan_set_track+0x25/0x30 __kasan_kmalloc+0xa2/0xb0 iopt_alloc_area_pages+0x94/0x560 iopt_map_user_pages+0x205/0x4e0 iommufd_ioas_map+0x329/0x5f0 iommufd_fops_ioctl+0x317/0x4b0 __x64_sys_ioctl+0x197/0x210 do_syscall_64+0x39/0xb0 entry_SYSCALL_64_after_hwframe+0x63/0xcd Freed by task 5770: kasan_save_stack+0x22/0x40 kasan_set_track+0x25/0x30 kasan_save_free_info+0x2e/0x40 ____kasan_slab_free+0x160/0x1c0 slab_free_freelist_hook+0x8b/0x1c0 __kmem_cache_free+0xaf/0x2d0 iopt_unmap_iova_range+0x288/0x5f0 iopt_unmap_all+0x27/0x50 iommufd_ioas_unmap+0x3d0/0x490 iommufd_fops_ioctl+0x317/0x4b0 __x64_sys_ioctl+0x197/0x210 do_syscall_64+0x39/0xb0 entry_SYSCALL_64_after_hwframe+0x63/0xcd The parallel unmap free'd iter->area the instant the lock was released. Fixes: 51fe6141f0f6 ("iommufd: Data structure to provide IOVA to PFN mapping") Reported-by: syzbot+6c8d756f238a75fc3eb8@syzkaller.appspotmail.com Closes: https://lore.kernel.org/r/000000000000905eba05fe38e9f2@google.com Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> --- drivers/iommu/iommufd/device.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/iommu/iommufd/device.c b/drivers/iommu/iommufd/device.c index 4f9b2142274ceb..29d05663d4d17a 100644 --- a/drivers/iommu/iommufd/device.c +++ b/drivers/iommu/iommufd/device.c @@ -553,8 +553,8 @@ void iommufd_access_unpin_pages(struct iommufd_access *access, iopt_area_iova_to_index( area, min(last_iova, iopt_area_last_iova(area)))); - up_read(&iopt->iova_rwsem); WARN_ON(!iopt_area_contig_done(&iter)); + up_read(&iopt->iova_rwsem); } EXPORT_SYMBOL_NS_GPL(iommufd_access_unpin_pages, IOMMUFD); -- 2.40.1 ^ permalink raw reply related [flat|nested] 7+ messages in thread
* RE: [PATCH rc 2/2] iommufd: Call iopt_area_contig_done() under the lock 2023-06-19 18:24 ` [PATCH rc 2/2] iommufd: Call iopt_area_contig_done() under the lock Jason Gunthorpe @ 2023-06-20 5:34 ` Tian, Kevin 0 siblings, 0 replies; 7+ messages in thread From: Tian, Kevin @ 2023-06-20 5:34 UTC (permalink / raw) To: Jason Gunthorpe, iommu@lists.linux.dev Cc: Lixiao Yang, Matthew Rosato, Nicolin Chen, syzbot+1ad12d16afca0e7d2dde@syzkaller.appspotmail.com, syzbot+6c8d756f238a75fc3eb8@syzkaller.appspotmail.com, Liu, Yi L > From: Jason Gunthorpe <jgg@nvidia.com> > Sent: Tuesday, June 20, 2023 2:25 AM > > The iter internally holds a pointer to the area and > iopt_area_contig_done() will dereference it. The pointer is not valid > outside the iova_rwsem. > > syzkaller reports: > > BUG: KASAN: slab-use-after-free in > iommufd_access_unpin_pages+0x363/0x370 > Read of size 8 at addr ffff888022286e20 by task syz-executor669/5771 > > CPU: 0 PID: 5771 Comm: syz-executor669 Not tainted 6.4.0-rc5-syzkaller- > 00313-g4c605260bc60 #0 > Hardware name: Google Google Compute Engine/Google Compute Engine, > BIOS Google 05/25/2023 > Call Trace: > <TASK> > dump_stack_lvl+0xd9/0x150 > print_address_description.constprop.0+0x2c/0x3c0 > kasan_report+0x11c/0x130 > iommufd_access_unpin_pages+0x363/0x370 > iommufd_test_access_unmap+0x24b/0x390 > iommufd_access_notify_unmap+0x24c/0x3a0 > iopt_unmap_iova_range+0x4c4/0x5f0 > iopt_unmap_all+0x27/0x50 > iommufd_ioas_unmap+0x3d0/0x490 > iommufd_fops_ioctl+0x317/0x4b0 > __x64_sys_ioctl+0x197/0x210 > do_syscall_64+0x39/0xb0 > entry_SYSCALL_64_after_hwframe+0x63/0xcd > RIP: 0033:0x7fec1dae3b19 > Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 11 15 00 00 90 48 89 f8 48 89 f7 48 > 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 > c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 > RSP: 002b:00007fec1da74308 EFLAGS: 00000246 ORIG_RAX: > 0000000000000010 > RAX: ffffffffffffffda RBX: 00007fec1db6b438 RCX: 00007fec1dae3b19 > RDX: 0000000020000100 RSI: 0000000000003b86 RDI: 0000000000000003 > RBP: 00007fec1db6b430 R08: 00007fec1da74700 R09: 0000000000000000 > R10: 00007fec1da74700 R11: 0000000000000246 R12: 00007fec1db6b43c > R13: 00007fec1db39074 R14: 6d6f692f7665642f R15: 0000000000022000 > </TASK> > > Allocated by task 5770: > kasan_save_stack+0x22/0x40 > kasan_set_track+0x25/0x30 > __kasan_kmalloc+0xa2/0xb0 > iopt_alloc_area_pages+0x94/0x560 > iopt_map_user_pages+0x205/0x4e0 > iommufd_ioas_map+0x329/0x5f0 > iommufd_fops_ioctl+0x317/0x4b0 > __x64_sys_ioctl+0x197/0x210 > do_syscall_64+0x39/0xb0 > entry_SYSCALL_64_after_hwframe+0x63/0xcd > > Freed by task 5770: > kasan_save_stack+0x22/0x40 > kasan_set_track+0x25/0x30 > kasan_save_free_info+0x2e/0x40 > ____kasan_slab_free+0x160/0x1c0 > slab_free_freelist_hook+0x8b/0x1c0 > __kmem_cache_free+0xaf/0x2d0 > iopt_unmap_iova_range+0x288/0x5f0 > iopt_unmap_all+0x27/0x50 > iommufd_ioas_unmap+0x3d0/0x490 > iommufd_fops_ioctl+0x317/0x4b0 > __x64_sys_ioctl+0x197/0x210 > do_syscall_64+0x39/0xb0 > entry_SYSCALL_64_after_hwframe+0x63/0xcd > > The parallel unmap free'd iter->area the instant the lock was released. > > Fixes: 51fe6141f0f6 ("iommufd: Data structure to provide IOVA to PFN > mapping") > Reported-by: syzbot+6c8d756f238a75fc3eb8@syzkaller.appspotmail.com > Closes: > https://lore.kernel.org/r/000000000000905eba05fe38e9f2@google.com > Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> Reviewed-by: Kevin Tian <kevin.tian@intel.com> ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2023-06-20 12:36 UTC | newest] Thread overview: 7+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2023-06-19 18:24 [PATCH rc 0/2] iommufd syzkaller fixes Jason Gunthorpe 2023-06-19 18:24 ` [PATCH rc 1/2] iommufd: Do not access the area pointer after unlocking Jason Gunthorpe 2023-06-20 4:42 ` Nicolin Chen 2023-06-20 5:30 ` Tian, Kevin 2023-06-20 12:36 ` Jason Gunthorpe 2023-06-19 18:24 ` [PATCH rc 2/2] iommufd: Call iopt_area_contig_done() under the lock Jason Gunthorpe 2023-06-20 5:34 ` Tian, Kevin
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox