Re: [syzbot] [iommu?] memory leak in iommu_fwspec_init

[Krystian Kaniewski <krystianmkaniewski@gmail.com>]

On 10/30/26 03:36, syzbot wrote:
> Hello,
> 
> syzbot found the following issue on:
> 
> HEAD commit:    65ba8f34ec88 Merge tag 'xtensa-20261027' of https://github..
> git tree:       upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=15067d31580000
> kernel config:  https://syzkaller.appspot.com/x/.config?x=fbf447a1375a1948
> dashboard link: https://syzkaller.appspot.com/bug?extid=fe84fc6a684e0beb86e2
> compiler:       gcc (Debian 14.2.0-19) 14.2.0, GNU ld (GNU Binutils for Debian) 2.44
> syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=10b22a3c580000
> 
> Downloadable assets:
> disk image: https://storage.googleapis.com/syzbot-assets/b4e738ce5f2b/disk-65ba8f34.raw.xz
> vmlinux: https://storage.googleapis.com/syzbot-assets/1de9d1ecbbb6/vmlinux-65ba8f34.xz
> kernel image: https://storage.googleapis.com/syzbot-assets/8a3d79b65181/bzImage-65ba8f34.xz
> 
> AI-generated root cause summary:
> A memory leak of `struct dev_iommu` occurs when `iommu_fwspec_init()` allocates
> `dev->iommu` via `dev_iommu_get()`, but subsequently fails on allocating the
> `iommu_fwspec` structure (e.g. via fault injection) and returns -ENOMEM without
> releasing `dev->iommu`. Furthermore, callers such as `iommu_mock_device_add()`
> do not invoke `dev_iommu_free()` on error from `iommu_fwspec_init()`. When
> device initialization fails and the device is released, `dev->iommu` remains
> allocated, causing an unreferenced object memory leak.
> 
> full analysis:  https://syzkaller.appspot.com/x/ai_root_cause?x=fe84fc6a684e0beb86e2
> 
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+fe84fc6a684e0beb86e2@syzkaller.appspotmail.com
> 
> BUG: memory leak
> unreferenced object 0xffff88812bad6bc0 (size 64):
>   comm "syz.0.26", pid 5965, jiffies 4294941985
>   hex dump (first 32 bytes):
>     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
>     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
>   backtrace (crc 0):
>     kmemleak_alloc_recursive include/linux/kmemleak.h:44 [inline]
>     slab_post_alloc_hook mm/slub.c:4733 [inline]
>     slab_alloc_node mm/slub.c:5033 [inline]
>     __kmalloc_cache_noprof+0x35f/0x3f0 mm/slub.c:5676
>     _kmalloc_noprof include/linux/slab.h:991 [inline]
>     _kzalloc_noprof include/linux/slab.h:1312 [inline]
>     dev_iommu_get drivers/iommu/iommu.c:408 [inline]
>     dev_iommu_get drivers/iommu/iommu.c:399 [inline]
>     iommu_fwspec_init+0x20d/0x240 drivers/iommu/iommu.c:3086
>     iommu_mock_device_add+0x29/0x90 drivers/iommu/iommu.c:385
>     mock_dev_create drivers/iommu/iommufd/selftest.c:1026 [inline]
>     iommufd_test_mock_domain drivers/iommu/iommufd/selftest.c:1068 [inline]
>     iommufd_test+0x1a97/0x2ec0 drivers/iommu/iommufd/selftest.c:2104
>     iommufd_fops_ioctl+0x1ed/0x370 drivers/iommu/iommufd/main.c:556
>     vfs_ioctl fs/ioctl.c:51 [inline]
>     __do_sys_ioctl fs/ioctl.c:597 [inline]
>     __se_sys_ioctl fs/ioctl.c:583 [inline]
>     __x64_sys_ioctl+0xf4/0x140 fs/ioctl.c:583
>     do_syscall_x64 arch/x86/entry/syscall_64.c:61 [inline]
>     do_syscall_64+0xe9/0x530 arch/x86/entry/syscall_64.c:84
>     entry_SYSCALL_64_after_hwframe+0x77/0x7f
> 
> connection error: failed to recv *flatrpc.ExecutorMessageRawT: EOF
> 
> 
> ---
> 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 syzbot to run the reproducer, reply with:
> #syz test: git://repo/address.git branch-or-commit-hash
> If you attach or paste a git patch, syzbot will apply it before testing.
> 
> 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
Please move the fix out of iommu_fwspec_init() and into
iommu_mock_device_add(), and leave iommu_fwspec_init() unchanged. The
same core-level approach for this leak was already rejected by Robin
Murphy on 2026-11-02 [1]. iommu_fwspec_init() is designed to run
together with iommu_probe_device() or with a caller that cleans up after
a failure, as of_iommu_configure() does. The defect is the early return
in iommu_mock_device_add().

The leak happens because iommu_mock_device_add() returns the error of
iommu_fwspec_init() without freeing dev->iommu. iommu_fwspec_init() can
allocate dev->iommu with dev_iommu_get() and then fail to allocate the
fwspec. The mock device has not been added at that point, so no bus
notifier will ever call iommu_release_device() for it, and the
put_device() in mock_dev_create() frees only the mock device. When
iommu_fwspec_init() fails, iommu_mock_device_add() should call
dev_iommu_free() if dev->iommu is set. The check is needed because
iommu_fwspec_init() can also fail before it allocates anything, for
example when dev_iommu_get() itself fails. The existing dev_iommu_free()
on the device_add() failure path is correct and must stay. One error
label shared by both failure paths is a clean way to write it.

Please change the tag to:

  Fixes: 2a918911ed3d ("iommufd: Register iommufd mock devices with fwspec")

That commit added the early return that leaks. The current tag names
72acd9df18f1, a v5.7 change, so stable tooling would try to carry a core
change to trees that do not even have the mock helper, which only exists
since v6.18.

The commit message has to describe the new placement: name the early
return in iommu_mock_device_add() as the cause and explain why nothing
else frees dev->iommu for a mock device that was never added.

While rewriting the message, please also keep it short. From the
kmemleak report, the allocation chain (dev_iommu_get, iommu_fwspec_init
and iommu_mock_device_add with their source lines) is enough. The hex
dump, the object address, the comm line and the syscall entry frames can
go. Two or three short paragraphs are enough for this change.

[1] https://lore.kernel.org/all/7e209fb2-4bda-4207-9109-c67c8df41e05@arm.com/

-- 
Krystian Kaniewski