* [syzbot] [iommu?] KASAN: slab-use-after-free Read in free_iova
@ 2026-08-09 23:44 syzbot
2026-08-10 10:50 ` Robin Murphy
0 siblings, 1 reply; 7+ messages in thread
From: syzbot @ 2026-08-09 23:44 UTC (permalink / raw)
To: baolu.lu, dwmw2, iommu, joro, linux-kernel, robin.murphy,
syzkaller-bugs, will
Hello,
syzbot found the following issue on:
HEAD commit: 562bfb501c54 Merge tag 'integrity-v7.2-rc7' of git://git.k..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=17ba93b9580000
kernel config: https://syzkaller.appspot.com/x/.config?x=c05be6c9b0d36cb9
dashboard link: https://syzkaller.appspot.com/bug?extid=90c2d711b5218d10ce61
compiler: Debian clang version 22.1.8 (++20260613092233+e80beda6e255-1~exp1~20260613092250.77), Debian LLD 22.1.8
Unfortunately, I don't have any reproducer for this issue yet.
Downloadable assets:
disk image (non-bootable): https://storage.googleapis.com/syzbot-assets/d900f083ada3/non_bootable_disk-562bfb50.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/7580e6506574/vmlinux-562bfb50.xz
kernel image: https://storage.googleapis.com/syzbot-assets/883f7f234497/bzImage-562bfb50.xz
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+90c2d711b5218d10ce61@syzkaller.appspotmail.com
==================================================================
BUG: KASAN: slab-use-after-free in private_find_iova drivers/iommu/iova.c:285 [inline]
BUG: KASAN: slab-use-after-free in free_iova+0xab/0x200 drivers/iommu/iova.c:355
Read of size 8 at addr ffff888000274d60 by task syz.0.0/5327
CPU: 0 UID: 0 PID: 5327 Comm: syz.0.0 Not tainted syzkaller #0 PREEMPT(full)
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
Call Trace:
<IRQ>
dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120
print_address_description+0x55/0x1e0 mm/kasan/report.c:378
print_report+0x58/0x70 mm/kasan/report.c:482
kasan_report+0x117/0x150 mm/kasan/report.c:595
private_find_iova drivers/iommu/iova.c:285 [inline]
free_iova+0xab/0x200 drivers/iommu/iova.c:355
fq_ring_free_locked+0x1ab/0x310 drivers/iommu/dma-iommu.c:155
fq_ring_free drivers/iommu/dma-iommu.c:170 [inline]
fq_flush_timeout+0x234/0x2d0 drivers/iommu/dma-iommu.c:194
call_timer_fn+0x192/0x5e0 kernel/time/timer.c:1748
expire_timers kernel/time/timer.c:1799 [inline]
__run_timers kernel/time/timer.c:2374 [inline]
__run_timer_base+0x652/0x8b0 kernel/time/timer.c:2386
run_timer_base kernel/time/timer.c:2395 [inline]
run_timer_softirq+0xb7/0x170 kernel/time/timer.c:2405
handle_softirqs+0x225/0x840 kernel/softirq.c:622
__do_softirq kernel/softirq.c:656 [inline]
invoke_softirq kernel/softirq.c:496 [inline]
__irq_exit_rcu+0xca/0x220 kernel/softirq.c:735
irq_exit_rcu+0x9/0x30 kernel/softirq.c:752
instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1062 [inline]
sysvec_apic_timer_interrupt+0xa6/0xc0 arch/x86/kernel/apic/apic.c:1062
</IRQ>
<TASK>
asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:674
RIP: 0010:console_flush_one_record arch/x86/include/asm/irqflags.h:-1 [inline]
RIP: 0010:console_flush_all+0x7d2/0xaf0 kernel/printk/printk.c:3343
Code: ff ff e8 81 3b 21 00 90 0f 0b 90 e9 9c fc ff ff e8 73 3b 21 00 e8 ce 5d 2d 0a 48 85 db 74 c0 e8 64 3b 21 00 fb 48 8b 5c 24 18 <48> 8b 44 24 28 42 80 3c 20 00 4d 8d 77 58 74 08 4c 89 f7 e8 e6 6d
RSP: 0018:ffffc9000f6271e0 EFLAGS: 00000283
RAX: ffffffff81a5e75c RBX: ffffc9000f627340 RCX: 0000000000100000
RDX: ffffc9000edfa000 RSI: 000000000002c5aa RDI: 000000000002c5ab
RBP: ffffc9000f6272f0 R08: ffffffff9057c237 R09: 1ffffffff20af846
R10: dffffc0000000000 R11: fffffbfff20af847 R12: dffffc0000000000
R13: 0000000000000001 R14: 0000000000000000 R15: ffffffff8f471ce0
__console_flush_and_unlock kernel/printk/printk.c:3373 [inline]
console_unlock+0xd1/0x1c0 kernel/printk/printk.c:3413
vprintk_emit+0x485/0x560 kernel/printk/printk.c:2479
__warn_printf lib/bug.c:189 [inline]
__report_bug+0x3c5/0x570 lib/bug.c:249
report_bug_entry+0x19a/0x290 lib/bug.c:274
handle_bug+0xce/0x200 arch/x86/kernel/traps.c:431
exc_invalid_op+0x1a/0x50 arch/x86/kernel/traps.c:490
asm_exc_invalid_op+0x1a/0x20 arch/x86/include/asm/idtentry.h:593
RIP: 0010:debug_print_object+0x18a/0x230 lib/debugobjects.c:629
Code: f8 48 c1 e8 03 80 3c 18 00 74 08 4c 89 ff e8 3d 13 56 fd 4d 8b 0f 4c 89 ef 48 8b 74 24 08 48 89 ea 44 89 e1 4d 89 f0 ff 34 24 <67> 48 0f b9 3a 48 83 c4 08 ff 05 03 b3 77 0b 48 83 c4 10 5b 41 5c
RSP: 0018:ffffc9000f6276f0 EFLAGS: 00010246
RAX: 1ffffffff17decd0 RBX: dffffc0000000000 RCX: 0000000000000000
RDX: ffffffff8c4bf940 RSI: ffffffff8c4bf3c0 RDI: ffffffff90632440
RBP: ffffffff8c4bf940 R08: ffff8880002684e0 R09: ffffffff8bef79e0
R10: dffffc0000000000 R11: ffffffff81b33db0 R12: 0000000000000000
R13: ffffffff90632440 R14: ffff8880002684e0 R15: ffffffff8bef6680
__debug_check_no_obj_freed lib/debugobjects.c:1171 [inline]
debug_check_no_obj_freed+0x2e3/0x450 lib/debugobjects.c:1201
slab_free_hook mm/slub.c:2608 [inline]
slab_free mm/slub.c:6377 [inline]
kfree+0x13e/0x640 mm/slub.c:6692
iommu_domain_free drivers/iommu/iommu.c:2131 [inline]
iommu_deinit_device+0x401/0x840 drivers/iommu/iommu.c:600
__iommu_group_remove_device+0x1dd/0x270 drivers/iommu/iommu.c:764
iommu_release_device drivers/iommu/iommu.c:783 [inline]
iommu_bus_notifier+0x6d/0x2c0 drivers/iommu/iommu.c:1826
notifier_call_chain+0x1a5/0x3d0 kernel/notifier.c:85
blocking_notifier_call_chain+0x6a/0x90 kernel/notifier.c:380
bus_notify+0x143/0x180 drivers/base/bus.c:1086
device_del+0x740/0x8f0 drivers/base/core.c:3978
pci_destroy_dev drivers/pci/remove.c:46 [inline]
pci_remove_bus_device+0x12a/0x2a0 drivers/pci/remove.c:110
pci_stop_and_remove_bus_device drivers/pci/remove.c:129 [inline]
pci_stop_and_remove_bus_device_locked+0x7f/0xb0 drivers/pci/remove.c:136
remove_store+0xe5/0x150 drivers/pci/pci-sysfs.c:523
kernfs_fop_write_iter+0x3a4/0x540 fs/kernfs/file.c:345
new_sync_write fs/read_write.c:595 [inline]
vfs_write+0x612/0xba0 fs/read_write.c:687
ksys_write+0x150/0x270 fs/read_write.c:739
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x174/0x580 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f2afa79e019
Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 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 e8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007f2afb6f9fe8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
RAX: ffffffffffffffda RBX: 00007f2afaa25fa0 RCX: 00007f2afa79e019
RDX: 0000000000000001 RSI: 00002000000000c0 RDI: 0000000000000008
RBP: 00007f2afa83500c R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007f2afaa26038 R14: 00007f2afaa25fa0 R15: 00007fff4eb947c8
</TASK>
Allocated by task 1:
kasan_save_stack mm/kasan/common.c:57 [inline]
kasan_save_track+0x3e/0x80 mm/kasan/common.c:78
unpoison_slab_object mm/kasan/common.c:340 [inline]
__kasan_slab_alloc+0x6c/0x80 mm/kasan/common.c:366
kasan_slab_alloc include/linux/kasan.h:253 [inline]
slab_post_alloc_hook mm/slub.c:4584 [inline]
slab_alloc_node mm/slub.c:4917 [inline]
kmem_cache_alloc_noprof+0x2a0/0x5f0 mm/slub.c:4931
alloc_iova_mem drivers/iommu/iova.c:231 [inline]
alloc_and_init_iova drivers/iommu/iova.c:474 [inline]
__insert_new_range drivers/iommu/iova.c:489 [inline]
reserve_iova+0x2b0/0x480 drivers/iommu/iova.c:544
iova_reserve_pci_windows drivers/iommu/dma-iommu.c:521 [inline]
iova_reserve_iommu_regions drivers/iommu/dma-iommu.c:563 [inline]
iommu_dma_init_domain drivers/iommu/dma-iommu.c:723 [inline]
iommu_setup_dma_ops+0xa21/0x1820 drivers/iommu/dma-iommu.c:2159
bus_iommu_probe+0x296/0x470 drivers/iommu/iommu.c:1983
iommu_device_register+0x1af/0x210 drivers/iommu/iommu.c:307
intel_iommu_init+0x6f0/0x8e0 drivers/iommu/intel/iommu.c:2662
pci_iommu_init+0x38/0x70 arch/x86/kernel/pci-dma.c:174
do_one_initcall+0x250/0x870 init/main.c:1347
do_initcall_level+0x10a/0x1a0 init/main.c:1409
do_initcalls+0x59/0xa0 init/main.c:1425
kernel_init_freeable+0x29d/0x3e0 init/main.c:1658
kernel_init+0x1d/0x1d0 init/main.c:1548
ret_from_fork+0x514/0xb70 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
Freed by task 5327:
kasan_save_stack mm/kasan/common.c:57 [inline]
kasan_save_track+0x3e/0x80 mm/kasan/common.c:78
kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:584
poison_slab_object mm/kasan/common.c:253 [inline]
__kasan_slab_free+0x5c/0x80 mm/kasan/common.c:285
kasan_slab_free include/linux/kasan.h:235 [inline]
slab_free_hook mm/slub.c:2677 [inline]
slab_free mm/slub.c:6377 [inline]
kmem_cache_free+0x182/0x650 mm/slub.c:6504
free_iova_mem drivers/iommu/iova.c:237 [inline]
put_iova_domain+0xcc/0x100 drivers/iommu/iova.c:454
iommu_put_dma_cookie+0x45c/0x560 drivers/iommu/dma-iommu.c:431
iommu_domain_free drivers/iommu/iommu.c:2131 [inline]
iommu_deinit_device+0x401/0x840 drivers/iommu/iommu.c:600
__iommu_group_remove_device+0x1dd/0x270 drivers/iommu/iommu.c:764
iommu_release_device drivers/iommu/iommu.c:783 [inline]
iommu_bus_notifier+0x6d/0x2c0 drivers/iommu/iommu.c:1826
notifier_call_chain+0x1a5/0x3d0 kernel/notifier.c:85
blocking_notifier_call_chain+0x6a/0x90 kernel/notifier.c:380
bus_notify+0x143/0x180 drivers/base/bus.c:1086
device_del+0x740/0x8f0 drivers/base/core.c:3978
pci_destroy_dev drivers/pci/remove.c:46 [inline]
pci_remove_bus_device+0x12a/0x2a0 drivers/pci/remove.c:110
pci_stop_and_remove_bus_device drivers/pci/remove.c:129 [inline]
pci_stop_and_remove_bus_device_locked+0x7f/0xb0 drivers/pci/remove.c:136
remove_store+0xe5/0x150 drivers/pci/pci-sysfs.c:523
kernfs_fop_write_iter+0x3a4/0x540 fs/kernfs/file.c:345
new_sync_write fs/read_write.c:595 [inline]
vfs_write+0x612/0xba0 fs/read_write.c:687
ksys_write+0x150/0x270 fs/read_write.c:739
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x174/0x580 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
The buggy address belongs to the object at ffff888000274d40
which belongs to the cache iommu_iova of size 40
The buggy address is located 32 bytes inside of
freed 40-byte region [ffff888000274d40, ffff888000274d68)
The buggy address belongs to the physical page:
page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x274
flags: 0x7ff00000000000(node=0|zone=0|lastcpupid=0x7ff)
page_type: f5(slab)
raw: 007ff00000000000 ffff888030463500 dead000000000100 dead000000000122
raw: 0000000000000000 0000000800400040 00000000f5000000 0000000000000000
page dumped because: kasan: bad access detected
page_owner tracks the page as allocated
page last allocated via order 0, migratetype Unmovable, gfp_mask 0xd2820(GFP_ATOMIC|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_NOMEMALLOC), pid 1, tgid 1 (swapper/0), ts 8498569964, free_ts 0
set_page_owner include/linux/page_owner.h:32 [inline]
post_alloc_hook+0x1f9/0x250 mm/page_alloc.c:1859
prep_new_page mm/page_alloc.c:1867 [inline]
get_page_from_freelist+0x21fa/0x2270 mm/page_alloc.c:3946
__alloc_frozen_pages_noprof+0x18d/0x380 mm/page_alloc.c:5304
alloc_slab_page mm/slub.c:3266 [inline]
allocate_slab+0x79/0x5e0 mm/slub.c:3380
new_slab mm/slub.c:3426 [inline]
refill_objects+0x2d5/0x350 mm/slub.c:7310
refill_sheaf mm/slub.c:2804 [inline]
__pcs_replace_empty_main+0x2bf/0x6b0 mm/slub.c:4675
alloc_from_pcs mm/slub.c:4773 [inline]
slab_alloc_node mm/slub.c:4905 [inline]
kmem_cache_alloc_noprof+0x382/0x5f0 mm/slub.c:4931
alloc_iova_mem drivers/iommu/iova.c:231 [inline]
alloc_and_init_iova drivers/iommu/iova.c:474 [inline]
__insert_new_range drivers/iommu/iova.c:489 [inline]
reserve_iova+0x2b0/0x480 drivers/iommu/iova.c:544
iova_reserve_pci_windows drivers/iommu/dma-iommu.c:521 [inline]
iova_reserve_iommu_regions drivers/iommu/dma-iommu.c:563 [inline]
iommu_dma_init_domain drivers/iommu/dma-iommu.c:723 [inline]
iommu_setup_dma_ops+0xa21/0x1820 drivers/iommu/dma-iommu.c:2159
bus_iommu_probe+0x296/0x470 drivers/iommu/iommu.c:1983
iommu_device_register+0x1af/0x210 drivers/iommu/iommu.c:307
intel_iommu_init+0x6f0/0x8e0 drivers/iommu/intel/iommu.c:2662
pci_iommu_init+0x38/0x70 arch/x86/kernel/pci-dma.c:174
do_one_initcall+0x250/0x870 init/main.c:1347
do_initcall_level+0x10a/0x1a0 init/main.c:1409
do_initcalls+0x59/0xa0 init/main.c:1425
page_owner free stack trace missing
Memory state around the buggy address:
ffff888000274c00: 00 00 00 00 00 fc fc fc 00 00 00 00 00 fc fc fc
ffff888000274c80: fa fb fb fb fb fc fc fc fa fb fb fb fb fc fc fc
>ffff888000274d00: fa fb fb fb fb fc fc fc fa fb fb fb fb fc fc fc
^
ffff888000274d80: fa fb fb fb fb fc fc fc 00 00 00 00 00 fc fc fc
ffff888000274e00: 00 00 00 00 00 fc fc fc 00 00 00 00 00 fc fc fc
==================================================================
----------------
Code disassembly (best guess), 1 bytes skipped:
0: ff ljmp (bad)
1: e8 81 3b 21 00 call 0x213b87
6: 90 nop
7: 0f 0b ud2
9: 90 nop
a: e9 9c fc ff ff jmp 0xfffffcab
f: e8 73 3b 21 00 call 0x213b87
14: e8 ce 5d 2d 0a call 0xa2d5de7
19: 48 85 db test %rbx,%rbx
1c: 74 c0 je 0xffffffde
1e: e8 64 3b 21 00 call 0x213b87
23: fb sti
24: 48 8b 5c 24 18 mov 0x18(%rsp),%rbx
* 29: 48 8b 44 24 28 mov 0x28(%rsp),%rax <-- trapping instruction
2e: 42 80 3c 20 00 cmpb $0x0,(%rax,%r12,1)
33: 4d 8d 77 58 lea 0x58(%r15),%r14
37: 74 08 je 0x41
39: 4c 89 f7 mov %r14,%rdi
3c: e8 .byte 0xe8
3d: e6 6d out %al,$0x6d
---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
If the report is already addressed, let syzbot know by replying with:
#syz fix: exact-commit-title
If you want to overwrite report's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)
If the report is a duplicate of another one, reply with:
#syz dup: exact-subject-of-another-report
If you want to undo deduplication, reply with:
#syz undup
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [syzbot] [iommu?] KASAN: slab-use-after-free Read in free_iova
2026-08-09 23:44 [syzbot] [iommu?] KASAN: slab-use-after-free Read in free_iova syzbot
@ 2026-08-10 10:50 ` Robin Murphy
2026-08-10 17:32 ` Jason Gunthorpe
0 siblings, 1 reply; 7+ messages in thread
From: Robin Murphy @ 2026-08-10 10:50 UTC (permalink / raw)
To: syzbot, baolu.lu, dwmw2, iommu, joro, linux-kernel,
syzkaller-bugs, will
On 2026-08-10 12:44 am, syzbot wrote:
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit: 562bfb501c54 Merge tag 'integrity-v7.2-rc7' of git://git.k..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=17ba93b9580000
> kernel config: https://syzkaller.appspot.com/x/.config?x=c05be6c9b0d36cb9
> dashboard link: https://syzkaller.appspot.com/bug?extid=90c2d711b5218d10ce61
> compiler: Debian clang version 22.1.8 (++20260613092233+e80beda6e255-1~exp1~20260613092250.77), Debian LLD 22.1.8
>
> Unfortunately, I don't have any reproducer for this issue yet.
>
> Downloadable assets:
> disk image (non-bootable): https://storage.googleapis.com/syzbot-assets/d900f083ada3/non_bootable_disk-562bfb50.raw.xz
> vmlinux: https://storage.googleapis.com/syzbot-assets/7580e6506574/vmlinux-562bfb50.xz
> kernel image: https://storage.googleapis.com/syzbot-assets/883f7f234497/bzImage-562bfb50.xz
>
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+90c2d711b5218d10ce61@syzkaller.appspotmail.com
>
> ==================================================================
> BUG: KASAN: slab-use-after-free in private_find_iova drivers/iommu/iova.c:285 [inline]
> BUG: KASAN: slab-use-after-free in free_iova+0xab/0x200 drivers/iommu/iova.c:355
> Read of size 8 at addr ffff888000274d60 by task syz.0.0/5327
>
> CPU: 0 UID: 0 PID: 5327 Comm: syz.0.0 Not tainted syzkaller #0 PREEMPT(full)
> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
> Call Trace:
> <IRQ>
> dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120
> print_address_description+0x55/0x1e0 mm/kasan/report.c:378
> print_report+0x58/0x70 mm/kasan/report.c:482
> kasan_report+0x117/0x150 mm/kasan/report.c:595
> private_find_iova drivers/iommu/iova.c:285 [inline]
> free_iova+0xab/0x200 drivers/iommu/iova.c:355
> fq_ring_free_locked+0x1ab/0x310 drivers/iommu/dma-iommu.c:155
> fq_ring_free drivers/iommu/dma-iommu.c:170 [inline]
> fq_flush_timeout+0x234/0x2d0 drivers/iommu/dma-iommu.c:194
So apparently the timer is firing with a non-empty queue...
> call_timer_fn+0x192/0x5e0 kernel/time/timer.c:1748
> expire_timers kernel/time/timer.c:1799 [inline]
> __run_timers kernel/time/timer.c:2374 [inline]
> __run_timer_base+0x652/0x8b0 kernel/time/timer.c:2386
> run_timer_base kernel/time/timer.c:2395 [inline]
> run_timer_softirq+0xb7/0x170 kernel/time/timer.c:2405
> handle_softirqs+0x225/0x840 kernel/softirq.c:622
> __do_softirq kernel/softirq.c:656 [inline]
> invoke_softirq kernel/softirq.c:496 [inline]
> __irq_exit_rcu+0xca/0x220 kernel/softirq.c:735
> irq_exit_rcu+0x9/0x30 kernel/softirq.c:752
> instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1062 [inline]
> sysvec_apic_timer_interrupt+0xa6/0xc0 arch/x86/kernel/apic/apic.c:1062
> </IRQ>
> <TASK>
> asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:674
> RIP: 0010:console_flush_one_record arch/x86/include/asm/irqflags.h:-1 [inline]
> RIP: 0010:console_flush_all+0x7d2/0xaf0 kernel/printk/printk.c:3343
> Code: ff ff e8 81 3b 21 00 90 0f 0b 90 e9 9c fc ff ff e8 73 3b 21 00 e8 ce 5d 2d 0a 48 85 db 74 c0 e8 64 3b 21 00 fb 48 8b 5c 24 18 <48> 8b 44 24 28 42 80 3c 20 00 4d 8d 77 58 74 08 4c 89 f7 e8 e6 6d
> RSP: 0018:ffffc9000f6271e0 EFLAGS: 00000283
> RAX: ffffffff81a5e75c RBX: ffffc9000f627340 RCX: 0000000000100000
> RDX: ffffc9000edfa000 RSI: 000000000002c5aa RDI: 000000000002c5ab
> RBP: ffffc9000f6272f0 R08: ffffffff9057c237 R09: 1ffffffff20af846
> R10: dffffc0000000000 R11: fffffbfff20af847 R12: dffffc0000000000
> R13: 0000000000000001 R14: 0000000000000000 R15: ffffffff8f471ce0
> __console_flush_and_unlock kernel/printk/printk.c:3373 [inline]
> console_unlock+0xd1/0x1c0 kernel/printk/printk.c:3413
> vprintk_emit+0x485/0x560 kernel/printk/printk.c:2479
> __warn_printf lib/bug.c:189 [inline]
> __report_bug+0x3c5/0x570 lib/bug.c:249
> report_bug_entry+0x19a/0x290 lib/bug.c:274
> handle_bug+0xce/0x200 arch/x86/kernel/traps.c:431
> exc_invalid_op+0x1a/0x50 arch/x86/kernel/traps.c:490
> asm_exc_invalid_op+0x1a/0x20 arch/x86/include/asm/idtentry.h:593
> RIP: 0010:debug_print_object+0x18a/0x230 lib/debugobjects.c:629
> Code: f8 48 c1 e8 03 80 3c 18 00 74 08 4c 89 ff e8 3d 13 56 fd 4d 8b 0f 4c 89 ef 48 8b 74 24 08 48 89 ea 44 89 e1 4d 89 f0 ff 34 24 <67> 48 0f b9 3a 48 83 c4 08 ff 05 03 b3 77 0b 48 83 c4 10 5b 41 5c
> RSP: 0018:ffffc9000f6276f0 EFLAGS: 00010246
> RAX: 1ffffffff17decd0 RBX: dffffc0000000000 RCX: 0000000000000000
> RDX: ffffffff8c4bf940 RSI: ffffffff8c4bf3c0 RDI: ffffffff90632440
> RBP: ffffffff8c4bf940 R08: ffff8880002684e0 R09: ffffffff8bef79e0
> R10: dffffc0000000000 R11: ffffffff81b33db0 R12: 0000000000000000
> R13: ffffffff90632440 R14: ffff8880002684e0 R15: ffffffff8bef6680
> __debug_check_no_obj_freed lib/debugobjects.c:1171 [inline]
> debug_check_no_obj_freed+0x2e3/0x450 lib/debugobjects.c:1201
> slab_free_hook mm/slub.c:2608 [inline]
> slab_free mm/slub.c:6377 [inline]
> kfree+0x13e/0x640 mm/slub.c:6692
> iommu_domain_free drivers/iommu/iommu.c:2131 [inline]
> iommu_deinit_device+0x401/0x840 drivers/iommu/iommu.c:600
> __iommu_group_remove_device+0x1dd/0x270 drivers/iommu/iommu.c:764
> iommu_release_device drivers/iommu/iommu.c:783 [inline]
> iommu_bus_notifier+0x6d/0x2c0 drivers/iommu/iommu.c:1826
> notifier_call_chain+0x1a5/0x3d0 kernel/notifier.c:85
> blocking_notifier_call_chain+0x6a/0x90 kernel/notifier.c:380
> bus_notify+0x143/0x180 drivers/base/bus.c:1086
> device_del+0x740/0x8f0 drivers/base/core.c:3978
> pci_destroy_dev drivers/pci/remove.c:46 [inline]
> pci_remove_bus_device+0x12a/0x2a0 drivers/pci/remove.c:110
> pci_stop_and_remove_bus_device drivers/pci/remove.c:129 [inline]
> pci_stop_and_remove_bus_device_locked+0x7f/0xb0 drivers/pci/remove.c:136
> remove_store+0xe5/0x150 drivers/pci/pci-sysfs.c:523
> kernfs_fop_write_iter+0x3a4/0x540 fs/kernfs/file.c:345
> new_sync_write fs/read_write.c:595 [inline]
> vfs_write+0x612/0xba0 fs/read_write.c:687
> ksys_write+0x150/0x270 fs/read_write.c:739
> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
> do_syscall_64+0x174/0x580 arch/x86/entry/syscall_64.c:94
> entry_SYSCALL_64_after_hwframe+0x77/0x7f
> RIP: 0033:0x7f2afa79e019
> Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 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 e8 ff ff ff f7 d8 64 89 01 48
> RSP: 002b:00007f2afb6f9fe8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
> RAX: ffffffffffffffda RBX: 00007f2afaa25fa0 RCX: 00007f2afa79e019
> RDX: 0000000000000001 RSI: 00002000000000c0 RDI: 0000000000000008
> RBP: 00007f2afa83500c R08: 0000000000000000 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
> R13: 00007f2afaa26038 R14: 00007f2afaa25fa0 R15: 00007fff4eb947c8
> </TASK>
>
> Allocated by task 1:
> kasan_save_stack mm/kasan/common.c:57 [inline]
> kasan_save_track+0x3e/0x80 mm/kasan/common.c:78
> unpoison_slab_object mm/kasan/common.c:340 [inline]
> __kasan_slab_alloc+0x6c/0x80 mm/kasan/common.c:366
> kasan_slab_alloc include/linux/kasan.h:253 [inline]
> slab_post_alloc_hook mm/slub.c:4584 [inline]
> slab_alloc_node mm/slub.c:4917 [inline]
> kmem_cache_alloc_noprof+0x2a0/0x5f0 mm/slub.c:4931
> alloc_iova_mem drivers/iommu/iova.c:231 [inline]
> alloc_and_init_iova drivers/iommu/iova.c:474 [inline]
> __insert_new_range drivers/iommu/iova.c:489 [inline]
> reserve_iova+0x2b0/0x480 drivers/iommu/iova.c:544
> iova_reserve_pci_windows drivers/iommu/dma-iommu.c:521 [inline]
> iova_reserve_iommu_regions drivers/iommu/dma-iommu.c:563 [inline]
> iommu_dma_init_domain drivers/iommu/dma-iommu.c:723 [inline]
> iommu_setup_dma_ops+0xa21/0x1820 drivers/iommu/dma-iommu.c:2159
> bus_iommu_probe+0x296/0x470 drivers/iommu/iommu.c:1983
> iommu_device_register+0x1af/0x210 drivers/iommu/iommu.c:307
> intel_iommu_init+0x6f0/0x8e0 drivers/iommu/intel/iommu.c:2662
> pci_iommu_init+0x38/0x70 arch/x86/kernel/pci-dma.c:174
> do_one_initcall+0x250/0x870 init/main.c:1347
> do_initcall_level+0x10a/0x1a0 init/main.c:1409
> do_initcalls+0x59/0xa0 init/main.c:1425
> kernel_init_freeable+0x29d/0x3e0 init/main.c:1658
> kernel_init+0x1d/0x1d0 init/main.c:1548
> ret_from_fork+0x514/0xb70 arch/x86/kernel/process.c:158
> ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
>
> Freed by task 5327:
> kasan_save_stack mm/kasan/common.c:57 [inline]
> kasan_save_track+0x3e/0x80 mm/kasan/common.c:78
> kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:584
> poison_slab_object mm/kasan/common.c:253 [inline]
> __kasan_slab_free+0x5c/0x80 mm/kasan/common.c:285
> kasan_slab_free include/linux/kasan.h:235 [inline]
> slab_free_hook mm/slub.c:2677 [inline]
> slab_free mm/slub.c:6377 [inline]
> kmem_cache_free+0x182/0x650 mm/slub.c:6504
> free_iova_mem drivers/iommu/iova.c:237 [inline]
> put_iova_domain+0xcc/0x100 drivers/iommu/iova.c:454
...except that right in between here we've called iommu_dma_free_fq()
which would have already invoked timer_delete_sync() and freed the queue
itself. Wut?
There is the "if (!cookie->fq_domain)" bypass, but I can't see how that
could be legitimately be taken given that we must have already observed
fq_domain being non-NULL in order to have any IOVAs in the queue to
begin with, and once it is set we never clear it. Has something else
corrupted the iommu_domain::iova_cookie?
Although given the allocation backtrace above, it also looks
suspiciously wrong that a reserved IOVA could have ended up on a flush
queue, so this whole thing starts to look like a symptom of one or more
bugs elsewhere rather than an issue in iommu-dma itself...
Thansk,
Robin.
> iommu_put_dma_cookie+0x45c/0x560 drivers/iommu/dma-iommu.c:431
> iommu_domain_free drivers/iommu/iommu.c:2131 [inline]
> iommu_deinit_device+0x401/0x840 drivers/iommu/iommu.c:600
> __iommu_group_remove_device+0x1dd/0x270 drivers/iommu/iommu.c:764
> iommu_release_device drivers/iommu/iommu.c:783 [inline]
> iommu_bus_notifier+0x6d/0x2c0 drivers/iommu/iommu.c:1826
> notifier_call_chain+0x1a5/0x3d0 kernel/notifier.c:85
> blocking_notifier_call_chain+0x6a/0x90 kernel/notifier.c:380
> bus_notify+0x143/0x180 drivers/base/bus.c:1086
> device_del+0x740/0x8f0 drivers/base/core.c:3978
> pci_destroy_dev drivers/pci/remove.c:46 [inline]
> pci_remove_bus_device+0x12a/0x2a0 drivers/pci/remove.c:110
> pci_stop_and_remove_bus_device drivers/pci/remove.c:129 [inline]
> pci_stop_and_remove_bus_device_locked+0x7f/0xb0 drivers/pci/remove.c:136
> remove_store+0xe5/0x150 drivers/pci/pci-sysfs.c:523
> kernfs_fop_write_iter+0x3a4/0x540 fs/kernfs/file.c:345
> new_sync_write fs/read_write.c:595 [inline]
> vfs_write+0x612/0xba0 fs/read_write.c:687
> ksys_write+0x150/0x270 fs/read_write.c:739
> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
> do_syscall_64+0x174/0x580 arch/x86/entry/syscall_64.c:94
> entry_SYSCALL_64_after_hwframe+0x77/0x7f
>
> The buggy address belongs to the object at ffff888000274d40
> which belongs to the cache iommu_iova of size 40
> The buggy address is located 32 bytes inside of
> freed 40-byte region [ffff888000274d40, ffff888000274d68)
>
> The buggy address belongs to the physical page:
> page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x274
> flags: 0x7ff00000000000(node=0|zone=0|lastcpupid=0x7ff)
> page_type: f5(slab)
> raw: 007ff00000000000 ffff888030463500 dead000000000100 dead000000000122
> raw: 0000000000000000 0000000800400040 00000000f5000000 0000000000000000
> page dumped because: kasan: bad access detected
> page_owner tracks the page as allocated
> page last allocated via order 0, migratetype Unmovable, gfp_mask 0xd2820(GFP_ATOMIC|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_NOMEMALLOC), pid 1, tgid 1 (swapper/0), ts 8498569964, free_ts 0
> set_page_owner include/linux/page_owner.h:32 [inline]
> post_alloc_hook+0x1f9/0x250 mm/page_alloc.c:1859
> prep_new_page mm/page_alloc.c:1867 [inline]
> get_page_from_freelist+0x21fa/0x2270 mm/page_alloc.c:3946
> __alloc_frozen_pages_noprof+0x18d/0x380 mm/page_alloc.c:5304
> alloc_slab_page mm/slub.c:3266 [inline]
> allocate_slab+0x79/0x5e0 mm/slub.c:3380
> new_slab mm/slub.c:3426 [inline]
> refill_objects+0x2d5/0x350 mm/slub.c:7310
> refill_sheaf mm/slub.c:2804 [inline]
> __pcs_replace_empty_main+0x2bf/0x6b0 mm/slub.c:4675
> alloc_from_pcs mm/slub.c:4773 [inline]
> slab_alloc_node mm/slub.c:4905 [inline]
> kmem_cache_alloc_noprof+0x382/0x5f0 mm/slub.c:4931
> alloc_iova_mem drivers/iommu/iova.c:231 [inline]
> alloc_and_init_iova drivers/iommu/iova.c:474 [inline]
> __insert_new_range drivers/iommu/iova.c:489 [inline]
> reserve_iova+0x2b0/0x480 drivers/iommu/iova.c:544
> iova_reserve_pci_windows drivers/iommu/dma-iommu.c:521 [inline]
> iova_reserve_iommu_regions drivers/iommu/dma-iommu.c:563 [inline]
> iommu_dma_init_domain drivers/iommu/dma-iommu.c:723 [inline]
> iommu_setup_dma_ops+0xa21/0x1820 drivers/iommu/dma-iommu.c:2159
> bus_iommu_probe+0x296/0x470 drivers/iommu/iommu.c:1983
> iommu_device_register+0x1af/0x210 drivers/iommu/iommu.c:307
> intel_iommu_init+0x6f0/0x8e0 drivers/iommu/intel/iommu.c:2662
> pci_iommu_init+0x38/0x70 arch/x86/kernel/pci-dma.c:174
> do_one_initcall+0x250/0x870 init/main.c:1347
> do_initcall_level+0x10a/0x1a0 init/main.c:1409
> do_initcalls+0x59/0xa0 init/main.c:1425
> page_owner free stack trace missing
>
> Memory state around the buggy address:
> ffff888000274c00: 00 00 00 00 00 fc fc fc 00 00 00 00 00 fc fc fc
> ffff888000274c80: fa fb fb fb fb fc fc fc fa fb fb fb fb fc fc fc
>> ffff888000274d00: fa fb fb fb fb fc fc fc fa fb fb fb fb fc fc fc
> ^
> ffff888000274d80: fa fb fb fb fb fc fc fc 00 00 00 00 00 fc fc fc
> ffff888000274e00: 00 00 00 00 00 fc fc fc 00 00 00 00 00 fc fc fc
> ==================================================================
> ----------------
> Code disassembly (best guess), 1 bytes skipped:
> 0: ff ljmp (bad)
> 1: e8 81 3b 21 00 call 0x213b87
> 6: 90 nop
> 7: 0f 0b ud2
> 9: 90 nop
> a: e9 9c fc ff ff jmp 0xfffffcab
> f: e8 73 3b 21 00 call 0x213b87
> 14: e8 ce 5d 2d 0a call 0xa2d5de7
> 19: 48 85 db test %rbx,%rbx
> 1c: 74 c0 je 0xffffffde
> 1e: e8 64 3b 21 00 call 0x213b87
> 23: fb sti
> 24: 48 8b 5c 24 18 mov 0x18(%rsp),%rbx
> * 29: 48 8b 44 24 28 mov 0x28(%rsp),%rax <-- trapping instruction
> 2e: 42 80 3c 20 00 cmpb $0x0,(%rax,%r12,1)
> 33: 4d 8d 77 58 lea 0x58(%r15),%r14
> 37: 74 08 je 0x41
> 39: 4c 89 f7 mov %r14,%rdi
> 3c: e8 .byte 0xe8
> 3d: e6 6d out %al,$0x6d
>
>
> ---
> This report is generated by a bot. It may contain errors.
> See https://goo.gl/tpsmEJ for more information about syzbot.
> syzbot engineers can be reached at syzkaller@googlegroups.com.
>
> syzbot will keep track of this issue. See:
> https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
>
> If the report is already addressed, let syzbot know by replying with:
> #syz fix: exact-commit-title
>
> If you want to overwrite report's subsystems, reply with:
> #syz set subsystems: new-subsystem
> (See the list of subsystem names on the web dashboard)
>
> If the report is a duplicate of another one, reply with:
> #syz dup: exact-subject-of-another-report
>
> If you want to undo deduplication, reply with:
> #syz undup
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [syzbot] [iommu?] KASAN: slab-use-after-free Read in free_iova
2026-08-10 10:50 ` Robin Murphy
@ 2026-08-10 17:32 ` Jason Gunthorpe
2026-08-11 9:48 ` Will Deacon
2026-08-11 12:57 ` Robin Murphy
0 siblings, 2 replies; 7+ messages in thread
From: Jason Gunthorpe @ 2026-08-10 17:32 UTC (permalink / raw)
To: Robin Murphy
Cc: syzbot, baolu.lu, dwmw2, iommu, joro, linux-kernel,
syzkaller-bugs, will
On Mon, Aug 10, 2026 at 11:50:28AM +0100, Robin Murphy wrote:
> > Freed by task 5327:
> > kasan_save_stack mm/kasan/common.c:57 [inline]
> > kasan_save_track+0x3e/0x80 mm/kasan/common.c:78
> > kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:584
> > poison_slab_object mm/kasan/common.c:253 [inline]
> > __kasan_slab_free+0x5c/0x80 mm/kasan/common.c:285
> > kasan_slab_free include/linux/kasan.h:235 [inline]
> > slab_free_hook mm/slub.c:2677 [inline]
> > slab_free mm/slub.c:6377 [inline]
> > kmem_cache_free+0x182/0x650 mm/slub.c:6504
> > free_iova_mem drivers/iommu/iova.c:237 [inline]
> > put_iova_domain+0xcc/0x100 drivers/iommu/iova.c:454
>
> ...except that right in between here we've called iommu_dma_free_fq() which
> would have already invoked timer_delete_sync() and freed the queue itself.
> Wut?
I've been feeding syzkaller riddles to the best AI I can get and it is
surprisingly good.. So, for this it guesses:
---
timer_delete_sync() does stop already scheduled work, but it does not
prevent a future mod_timer() from re-scheduling the now-deleted timer.
The probable sequence is:
1. A DMA unmap queues an IOVA and sets fq_timer_on = 1 at dma-iommu.c
(line 243), but has not yet executed mod_timer().
2. Concurrent PCI removal frees the device's default IOMMU
domain.
3. iommu_dma_free_fq() calls timer_delete_sync() at dma-iommu.c (line
274). Because the timer is not pending at that instant, it returns.
4. Teardown frees the flush queue and all IOVA-tree nodes through
put_iova_domain() (line 446).
5. The unmap path resumes and executes mod_timer(), rearming a timer
embedded in the soon-to-be-freed DMA cookie.
6. fq_flush_timeout() later runs and calls free_iova_fast(). It
traverses the already-destroyed IOVA rbtree, producing the reported
UAF in private_find_iova() (line 275).
---
Which seems plausible to me.. So it is a bug in a driver allowing a
dma API operation to be outstanding after it has been removed?
syzkaller console showed it did trigger a remove of a PCI function:
open("./sys/bus/pci/devices/0000:00:01.0/remove", O_WRONLY)
write(fd, "1", 1)
But I couldn't guess what device that was, if someone from syzkaller
land can clarify what they have plugged in there it might help.
The AI guessed on a GCE VM it was a display adaptor, but I don't see
how it could know that.
It would be a nice improvement to the CONFIG DMA DEBUGGING to keep
track of the driver bound state and blow up directly on all these
forbidden combinations.
Jason
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [syzbot] [iommu?] KASAN: slab-use-after-free Read in free_iova
2026-08-10 17:32 ` Jason Gunthorpe
@ 2026-08-11 9:48 ` Will Deacon
2026-08-11 13:49 ` Jason Gunthorpe
2026-08-11 12:57 ` Robin Murphy
1 sibling, 1 reply; 7+ messages in thread
From: Will Deacon @ 2026-08-11 9:48 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Robin Murphy, syzbot, baolu.lu, dwmw2, iommu, joro, linux-kernel,
syzkaller-bugs
On Mon, Aug 10, 2026 at 02:32:30PM -0300, Jason Gunthorpe wrote:
> On Mon, Aug 10, 2026 at 11:50:28AM +0100, Robin Murphy wrote:
> > > Freed by task 5327:
> > > kasan_save_stack mm/kasan/common.c:57 [inline]
> > > kasan_save_track+0x3e/0x80 mm/kasan/common.c:78
> > > kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:584
> > > poison_slab_object mm/kasan/common.c:253 [inline]
> > > __kasan_slab_free+0x5c/0x80 mm/kasan/common.c:285
> > > kasan_slab_free include/linux/kasan.h:235 [inline]
> > > slab_free_hook mm/slub.c:2677 [inline]
> > > slab_free mm/slub.c:6377 [inline]
> > > kmem_cache_free+0x182/0x650 mm/slub.c:6504
> > > free_iova_mem drivers/iommu/iova.c:237 [inline]
> > > put_iova_domain+0xcc/0x100 drivers/iommu/iova.c:454
> >
> > ...except that right in between here we've called iommu_dma_free_fq() which
> > would have already invoked timer_delete_sync() and freed the queue itself.
> > Wut?
>
> I've been feeding syzkaller riddles to the best AI I can get and it is
> surprisingly good.. So, for this it guesses:
Huh, that's a pretty good idea. Do you just dunk the report in verbatim,
or do you have a cleverly crafted prompt that you're having more success
with?
Will
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [syzbot] [iommu?] KASAN: slab-use-after-free Read in free_iova
2026-08-10 17:32 ` Jason Gunthorpe
2026-08-11 9:48 ` Will Deacon
@ 2026-08-11 12:57 ` Robin Murphy
2026-08-11 13:11 ` Jason Gunthorpe
1 sibling, 1 reply; 7+ messages in thread
From: Robin Murphy @ 2026-08-11 12:57 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: syzbot, baolu.lu, dwmw2, iommu, joro, linux-kernel,
syzkaller-bugs, will
On 10/08/2026 6:32 pm, Jason Gunthorpe wrote:
> On Mon, Aug 10, 2026 at 11:50:28AM +0100, Robin Murphy wrote:
>>> Freed by task 5327:
>>> kasan_save_stack mm/kasan/common.c:57 [inline]
>>> kasan_save_track+0x3e/0x80 mm/kasan/common.c:78
>>> kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:584
>>> poison_slab_object mm/kasan/common.c:253 [inline]
>>> __kasan_slab_free+0x5c/0x80 mm/kasan/common.c:285
>>> kasan_slab_free include/linux/kasan.h:235 [inline]
>>> slab_free_hook mm/slub.c:2677 [inline]
>>> slab_free mm/slub.c:6377 [inline]
>>> kmem_cache_free+0x182/0x650 mm/slub.c:6504
>>> free_iova_mem drivers/iommu/iova.c:237 [inline]
>>> put_iova_domain+0xcc/0x100 drivers/iommu/iova.c:454
>>
>> ...except that right in between here we've called iommu_dma_free_fq() which
>> would have already invoked timer_delete_sync() and freed the queue itself.
>> Wut?
>
> I've been feeding syzkaller riddles to the best AI I can get and it is
> surprisingly good.. So, for this it guesses:
>
> ---
> timer_delete_sync() does stop already scheduled work, but it does not
> prevent a future mod_timer() from re-scheduling the now-deleted timer.
>
> The probable sequence is:
>
> 1. A DMA unmap queues an IOVA and sets fq_timer_on = 1 at dma-iommu.c
> (line 243), but has not yet executed mod_timer().
>
> 2. Concurrent PCI removal frees the device's default IOMMU
> domain.
>
> 3. iommu_dma_free_fq() calls timer_delete_sync() at dma-iommu.c (line
> 274). Because the timer is not pending at that instant, it returns.
>
> 4. Teardown frees the flush queue and all IOVA-tree nodes through
> put_iova_domain() (line 446).
>
> 5. The unmap path resumes and executes mod_timer(), rearming a timer
> embedded in the soon-to-be-freed DMA cookie.
But where would that unmap be? We're in a notifier near the end of
device_del() here - the device is already very very dead, so anyone
still using it for DMA doesn't simply have some subtle race. It
seemingly couldn't even be in the device's driver, since pci_stop_dev()
has also already unbound that, so it would presumably have to be an even
more egregious subsystem-level UAF...
As I say though, the fact that it always appears to be an IOVA from
reserve_iova() on the flush queue would seem to be the smoking gun
pointing to this being well outside the scope of normal operation
anyway. From one of the logs it seems that 00:01.0 belongs to lpc_ich,
which is an MFD driver, so given the fact that it's an on-board chipset
device, plus the tricks MFD plays to hang platform devices and their
drivers off a PCI device, I could well imagine it has never expected to
deal with removal very well, so I'm definitely leaning more toward some
prior state corruption triggering this...
Cheers,
Robin.
> 6. fq_flush_timeout() later runs and calls free_iova_fast(). It
> traverses the already-destroyed IOVA rbtree, producing the reported
> UAF in private_find_iova() (line 275).
> ---
>
> Which seems plausible to me.. So it is a bug in a driver allowing a
> dma API operation to be outstanding after it has been removed?
>
> syzkaller console showed it did trigger a remove of a PCI function:
>
> open("./sys/bus/pci/devices/0000:00:01.0/remove", O_WRONLY)
> write(fd, "1", 1)
>
> But I couldn't guess what device that was, if someone from syzkaller
> land can clarify what they have plugged in there it might help.
>
> The AI guessed on a GCE VM it was a display adaptor, but I don't see
> how it could know that.
>
> It would be a nice improvement to the CONFIG DMA DEBUGGING to keep
> track of the driver bound state and blow up directly on all these
> forbidden combinations.
>
> Jason
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [syzbot] [iommu?] KASAN: slab-use-after-free Read in free_iova
2026-08-11 12:57 ` Robin Murphy
@ 2026-08-11 13:11 ` Jason Gunthorpe
0 siblings, 0 replies; 7+ messages in thread
From: Jason Gunthorpe @ 2026-08-11 13:11 UTC (permalink / raw)
To: Robin Murphy
Cc: syzbot, baolu.lu, dwmw2, iommu, joro, linux-kernel,
syzkaller-bugs, will
On Tue, Aug 11, 2026 at 01:57:38PM +0100, Robin Murphy wrote:
> But where would that unmap be?
If the theory is right then the bug would be some concurrent driver
thread like a work queue/timer or a user thread going into a fops that
outlives the driver remove function. That thread would do the unmap.
This is an extremely common bug class in drivers at least..
eg DRM has lots of challenges in this area if the guess about VGA is
correct.
Regards,
Jason
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [syzbot] [iommu?] KASAN: slab-use-after-free Read in free_iova
2026-08-11 9:48 ` Will Deacon
@ 2026-08-11 13:49 ` Jason Gunthorpe
0 siblings, 0 replies; 7+ messages in thread
From: Jason Gunthorpe @ 2026-08-11 13:49 UTC (permalink / raw)
To: Will Deacon
Cc: Robin Murphy, syzbot, baolu.lu, dwmw2, iommu, joro, linux-kernel,
syzkaller-bugs
On Tue, Aug 11, 2026 at 10:48:05AM +0100, Will Deacon wrote:
> On Mon, Aug 10, 2026 at 02:32:30PM -0300, Jason Gunthorpe wrote:
> > On Mon, Aug 10, 2026 at 11:50:28AM +0100, Robin Murphy wrote:
> > > > Freed by task 5327:
> > > > kasan_save_stack mm/kasan/common.c:57 [inline]
> > > > kasan_save_track+0x3e/0x80 mm/kasan/common.c:78
> > > > kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:584
> > > > poison_slab_object mm/kasan/common.c:253 [inline]
> > > > __kasan_slab_free+0x5c/0x80 mm/kasan/common.c:285
> > > > kasan_slab_free include/linux/kasan.h:235 [inline]
> > > > slab_free_hook mm/slub.c:2677 [inline]
> > > > slab_free mm/slub.c:6377 [inline]
> > > > kmem_cache_free+0x182/0x650 mm/slub.c:6504
> > > > free_iova_mem drivers/iommu/iova.c:237 [inline]
> > > > put_iova_domain+0xcc/0x100 drivers/iommu/iova.c:454
> > >
> > > ...except that right in between here we've called iommu_dma_free_fq() which
> > > would have already invoked timer_delete_sync() and freed the queue itself.
> > > Wut?
> >
> > I've been feeding syzkaller riddles to the best AI I can get and it is
> > surprisingly good.. So, for this it guesses:
>
> Huh, that's a pretty good idea. Do you just dunk the report in verbatim,
> or do you have a cleverly crafted prompt that you're having more success
> with?
I usually take the email into a file, download any reproducer and just
feed it to it. 'Here is a bug description in xyz.txt what could be
wrong' and play the lottery. On this one it could understand the http
links and it fetched down the console logs and other information from
the dashboard on its own (This was GPT Sol 5.6)
Even if it isn't right out of the gate it is usually still interesting
and points at new things to think about
Like this theory about concurrent unmap is a good guess, but there is
a big gap between that guess and finding the source of the unmap.
Jason
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2026-08-11 13:49 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-08-09 23:44 [syzbot] [iommu?] KASAN: slab-use-after-free Read in free_iova syzbot
2026-08-10 10:50 ` Robin Murphy
2026-08-10 17:32 ` Jason Gunthorpe
2026-08-11 9:48 ` Will Deacon
2026-08-11 13:49 ` Jason Gunthorpe
2026-08-11 12:57 ` Robin Murphy
2026-08-11 13:11 ` Jason Gunthorpe
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.