[syzbot] [iommu?] memory leak in iommu_fwspec_init

[syzbot] [iommu?] memory leak in iommu_fwspec_init

[syzbot]

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

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

[syzbot]

syzbot has found a reproducer for the following issue on:

HEAD commit:    46fec1c3029b Merge tag 'sched-urgent-2026-11-01' of git://..
git tree:       git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
console output: https://syzkaller.appspot.com/x/log.txt?x=1263dc8d580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=441b6cc593d83cc4
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
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=107b1795580000

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 0xffff888129294b00 (size 64):
  comm "syz.3.20", pid 6865, jiffies 4294946901
  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


---
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.

Forwarded: [PATCH] iommu: Fix dev_iommu leak on mock fwspec initialization failure

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.

***

Subject: [PATCH] iommu: Fix dev_iommu leak on mock fwspec initialization failure
Author: diasyzhangqing@gmail.com

If iommu_fwspec_init() fails to allocate the fwspec after allocating
dev->iommu, iommu_mock_device_add() returns without freeing dev->iommu.
The mock device was never registered, so the normal IOMMU cleanup path
does not run, and releasing the mock device leaves dev_iommu leaked.

Clean up in iommu_mock_device_add() while holding iommu_probe_device_lock.
Only free dev->iommu if this call allocated it, preserving any pre-existing
object. Check for NULL since initialization can fail before allocation.

Fixes: 2a918911ed3d ("iommufd: Register iommufd mock devices with fwspec")
Reported-by: syzbot+fe84fc6a684e0beb86e2@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=fe84fc6a684e0beb86e2
Suggested-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Qing Zhang <diasyzhang@tencent.com>
---
I reproduced the same leak from the syzbot report. This fixes the mock
device path as Robin requested in response to Tal's patch [1].

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

#syz test: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master

 drivers/iommu/iommu.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index b486b8bbd1fc..207241a553b9 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -379,10 +379,14 @@ EXPORT_SYMBOL_GPL(iommu_device_register_bus);
 
 int iommu_mock_device_add(struct device *dev, struct iommu_device *iommu)
 {
+	bool dev_iommu_present;
 	int rc;
 
 	mutex_lock(&iommu_probe_device_lock);
+	dev_iommu_present = dev->iommu;
 	rc = iommu_fwspec_init(dev, iommu->fwnode);
+	if (rc && !dev_iommu_present && dev->iommu)
+		dev_iommu_free(dev);
 	mutex_unlock(&iommu_probe_device_lock);
 
 	if (rc)
-- 
2.43.7

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

[Krystian Kaniewski]

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

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

[Krystian Kaniewski]

On 11/6/26 16:08, Krystian Kaniewski wrote:
>> 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/
> 
Please disregard the previous mail in this thread. It was meant as
review feedback on syzbot's AI-generated patch for this report, which is
still in moderation and was not posted to this list. It does not refer
to Qing Zhang's patch, which already makes this fix in
iommu_mock_device_add(). Sorry for the noise.
-- 
Krystian Kaniewski

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

[syzbot]

Hello,

syzbot has tested the proposed patch and the reproducer did not trigger any issue:

Reported-by: syzbot+fe84fc6a684e0beb86e2@syzkaller.appspotmail.com
Tested-by: syzbot+fe84fc6a684e0beb86e2@syzkaller.appspotmail.com

Tested on:

commit:         6628e7d4 Linux 7.4-rc1
git tree:       upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=16f8be69580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=441b6cc593d83cc4
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
patch:          https://syzkaller.appspot.com/x/patch.diff?x=17cc3c8d580000

Note: testing is done by a robot and is best-effort only.