Re: [syzbot] [iommu?] WARNING in iommu_setup_default_domain

[Jason Gunthorpe]

On Thu, Oct 15, 2026 at 08:41:24PM -0700, syzbot wrote:
> Hello,
> 
> syzbot found the following issue on:
> 
> HEAD commit:    b88c841d1164 Merge tag 'input-for-v7.3-rc6' of git://git.k..
> git tree:       upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=117d540d580000
> kernel config:  https://syzkaller.appspot.com/x/.config?x=44ac479246d4559b
> dashboard link: https://syzkaller.appspot.com/bug?extid=2a4570d89a1e13003dbf
> compiler:       gcc (Debian 14.2.0-19) 14.2.0, GNU ld (GNU Binutils for Debian) 2.44
> userspace arch: i386
> 
> 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-b88c841d.raw.xz
> vmlinux: https://storage.googleapis.com/syzbot-assets/e27770b53aa6/vmlinux-b88c841d.xz
> kernel image: https://storage.googleapis.com/syzbot-assets/3a314a5eb19d/bzImage-b88c841d.xz
> 
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+2a4570d89a1e13003dbf@xxxxxxxxxxxxxxxxxxxxxxxxx
> 
> R10: 0000000000000000 R11: 0000000000000292 R12: 0000000000000000
> R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
>  </TASK>
> ------------[ cut here ]------------
> ret
> WARNING: drivers/iommu/iommu.c:3205 at iommu_setup_default_domain+0xbb6/0xf30 drivers/iommu/iommu.c:3205, CPU#2: syz.2.802/11603
> Modules linked in:

This is from a fault injection hit in the intel driver..

[  382.158650][T11603] FAULT_INJECTION: forcing a failure.
[  382.158650][T11603] name failslab, interval 1, probability 0, space 0, times 0

[..]

[  382.158831][T11603]  ? lockdep_hardirqs_on+0x7d/0x110
[  382.158850][T11603]  ? _raw_spin_unlock_irqrestore+0x3b/0x80
[  382.158869][T11603]  cache_tag_assign_domain+0x1f3/0x650
[  382.158888][T11603]  intel_iommu_attach_device+0x706/0xe00
[  382.158906][T11603]  ? __pfx_intel_iommu_attach_device+0x10/0x10
[  382.158921][T11603]  __iommu_attach_device+0x73/0x340
[  382.158935][T11603]  __iommu_device_set_domain+0x178/0x250
[  382.158951][T11603]  __iommu_group_set_domain_internal+0x1b1/0x450
[  382.158969][T11603]  iommu_setup_default_domain+0xb9b/0xf30
[  382.158990][T11603]  __iommu_probe_device+0x1174/0x1550
[  382.159007][T11603]  ? __pfx___iommu_probe_device+0x10/0x10
[  382.159029][T11603]  iommu_probe_device+0x28/0x130
[  382.159045][T11603]  iommu_bus_notifier+0x5b/0x110
[  382.159061][T11603]  notifier_call_chain+0x99/0x3f0

Which causes initial domain attach to fail:

                /*
                 * Drivers are not allowed to fail the first domain attach.
                 * The only way to recover from this is to fail attaching the
                 * iommu driver and call ops->release_device. Put the domain
                 * in group->default_domain so it is freed after.
                 */
                ret = __iommu_group_set_domain_internal(
                        group, dom, IOMMU_SET_DOMAIN_MUST_SUCCEED);
                if (WARN_ON(ret))
                        goto out_free_old;

Which we can't handle in any sane way.

Not sure what to do about this, it doesn't seem like a real bug to
worry about.

Jason