[syzbot] [fs?] memory leak in path_openat (4)

[syzbot] [fs?] memory leak in path_openat (4)

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit:    26260251022f Merge tag 'livepatching-for-7.3' of git://git..
git tree:       upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1196a179580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=6c1b5958b2d1207f
dashboard link: https://syzkaller.appspot.com/bug?extid=7666ed2c3d42196bf7e3
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=139f7179580000

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/0f75e7622b1f/disk-26260251.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/2bbff9fd7b60/vmlinux-26260251.xz
kernel image: https://storage.googleapis.com/syzbot-assets/95d733004907/bzImage-26260251.xz

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+7666ed2c3d42196bf7e3@syzkaller.appspotmail.com

2026/08/22 14:47:52 executed programs: 26
2026/08/22 14:47:59 executed programs: 40
2026/08/22 14:48:07 executed programs: 54
2026/08/22 14:48:14 executed programs: 68
BUG: memory leak
unreferenced object 0xffff88812811f9c0 (size 176):
  comm "syz.0.25", pid 6047, jiffies 4294943865
  hex dump (first 32 bytes):
    00 00 00 00 19 00 08 04 40 fc a8 85 ff ff ff ff  ........@.......
    00 02 38 03 81 88 ff ff 80 cd 61 11 81 88 ff ff  ..8.......a.....
  backtrace (crc 1214ee3a):
    kmemleak_alloc_recursive include/linux/kmemleak.h:44 [inline]
    slab_post_alloc_hook mm/slub.c:4599 [inline]
    slab_alloc_node mm/slub.c:4919 [inline]
    kmem_cache_alloc_noprof+0x352/0x440 mm/slub.c:4933
    alloc_empty_file+0x57/0x180 fs/file_table.c:262
    path_openat+0x44/0x11f0 fs/namei.c:4986
    do_file_open+0x121/0x200 fs/namei.c:5029
    do_sys_openat2+0xa7/0x150 fs/open.c:1417
    do_sys_open fs/open.c:1423 [inline]
    __do_sys_openat fs/open.c:1439 [inline]
    __se_sys_openat fs/open.c:1434 [inline]
    __x64_sys_openat+0x82/0xf0 fs/open.c:1434
    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

BUG: memory leak
unreferenced object 0xffff8881280ec188 (size 56):
  comm "syz.0.25", pid 6047, jiffies 4294943865
  hex dump (first 32 bytes):
    ff ff 01 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 2672a0c6):
    kmemleak_alloc_recursive include/linux/kmemleak.h:44 [inline]
    slab_post_alloc_hook mm/slub.c:4599 [inline]
    slab_alloc_node mm/slub.c:4919 [inline]
    kmem_cache_alloc_noprof+0x352/0x440 mm/slub.c:4933
    lsm_file_alloc security/security.c:171 [inline]
    security_file_alloc+0x30/0x250 security/security.c:2406
    init_file+0x3e/0x160 fs/file_table.c:184
    alloc_empty_file+0x75/0x180 fs/file_table.c:266
    path_openat+0x44/0x11f0 fs/namei.c:4986
    do_file_open+0x121/0x200 fs/namei.c:5029
    do_sys_openat2+0xa7/0x150 fs/open.c:1417
    do_sys_open fs/open.c:1423 [inline]
    __do_sys_openat fs/open.c:1439 [inline]
    __se_sys_openat fs/open.c:1434 [inline]
    __x64_sys_openat+0x82/0xf0 fs/open.c:1434
    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

BUG: memory leak
unreferenced object 0xffff88811161cd80 (size 192):
  comm "syz.0.25", pid 6047, jiffies 4294943865
  hex dump (first 32 bytes):
    c0 f9 11 28 81 88 ff ff 00 00 00 00 2c 00 00 01  ...(........,...
    b2 6d b2 0e 81 88 ff ff 00 00 00 00 00 00 00 00  .m..............
  backtrace (crc 6cdefeb4):
    kmemleak_alloc_recursive include/linux/kmemleak.h:44 [inline]
    slab_post_alloc_hook mm/slub.c:4599 [inline]
    slab_alloc_node mm/slub.c:4919 [inline]
    __kmalloc_cache_noprof+0x359/0x440 mm/slub.c:5480
    _kmalloc_noprof include/linux/slab.h:988 [inline]
    _kzalloc_noprof include/linux/slab.h:1309 [inline]
    iommufd_fops_open+0x24/0xe0 drivers/iommu/iommufd/main.c:319
    misc_open+0x12a/0x1f0 drivers/char/misc.c:163
    chrdev_open+0x108/0x310 fs/char_dev.c:411
    do_dentry_open+0x1fc/0x850 fs/open.c:996
    vfs_open+0x3d/0x1b0 fs/open.c:1101
    do_open fs/namei.c:4837 [inline]
    path_openat+0xde7/0x11f0 fs/namei.c:5000
    do_file_open+0x121/0x200 fs/namei.c:5029
    do_sys_openat2+0xa7/0x150 fs/open.c:1417
    do_sys_open fs/open.c:1423 [inline]
    __do_sys_openat fs/open.c:1439 [inline]
    __se_sys_openat fs/open.c:1434 [inline]
    __x64_sys_openat+0x82/0xf0 fs/open.c:1434
    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

BUG: memory leak
unreferenced object 0xffff888127dd4000 (size 256):
  comm "syz.0.25", pid 6047, jiffies 4294943865
  hex dump (first 32 bytes):
    01 00 00 00 01 00 00 00 04 00 00 00 01 00 00 00  ................
    00 00 00 00 00 00 00 00 01 48 cf 0a 81 88 ff ff  .........H......
  backtrace (crc 98731819):
    kmemleak_alloc_recursive include/linux/kmemleak.h:44 [inline]
    slab_post_alloc_hook mm/slub.c:4599 [inline]
    slab_alloc_node mm/slub.c:4919 [inline]
    __do_kmalloc_node mm/slub.c:5336 [inline]
    __kmalloc_noprof+0x3c2/0x560 mm/slub.c:5362
    _kmalloc_noprof include/linux/slab.h:992 [inline]
    _kzalloc_noprof include/linux/slab.h:1309 [inline]
    _iommufd_object_alloc+0x24/0x100 drivers/iommu/iommufd/main.c:41
    iommufd_ioas_alloc drivers/iommu/iommufd/ioas.c:28 [inline]
    iommufd_ioas_alloc_ioctl+0x46/0x160 drivers/iommu/iommufd/ioas.c:47
    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

BUG: memory leak
unreferenced object 0xffff88810eb26db0 (size 576):
  comm "syz.0.25", pid 6047, jiffies 4294943865
  hex dump (first 32 bytes):
    00 17 02 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    88 cd 61 11 81 88 ff ff c8 6d b2 0e 81 88 ff ff  ..a......m......
  backtrace (crc f41786a5):
    kmemleak_alloc_recursive include/linux/kmemleak.h:44 [inline]
    slab_post_alloc_hook mm/slub.c:4599 [inline]
    slab_alloc_node mm/slub.c:4919 [inline]
    kmem_cache_alloc_lru_noprof+0x350/0x440 mm/slub.c:4952
    xas_alloc+0xf1/0x110 lib/xarray.c:378
    xas_expand lib/xarray.c:590 [inline]
    xas_create+0x105/0x8a0 lib/xarray.c:661
    xas_store+0x7a/0xb20 lib/xarray.c:795
    __xa_alloc+0xec/0x200 lib/xarray.c:2005
    xa_alloc include/linux/xarray.h:878 [inline]
    _iommufd_object_alloc+0x9d/0x100 drivers/iommu/iommufd/main.c:56
    iommufd_ioas_alloc drivers/iommu/iommufd/ioas.c:28 [inline]
    iommufd_ioas_alloc_ioctl+0x46/0x160 drivers/iommu/iommufd/ioas.c:47
    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

BUG: memory leak
unreferenced object 0xffff88811161ccc0 (size 192):
  comm "syz.0.25", pid 6047, jiffies 4294943865
  hex dump (first 32 bytes):
    01 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 21b0f99b):
    kmemleak_alloc_recursive include/linux/kmemleak.h:44 [inline]
    slab_post_alloc_hook mm/slub.c:4599 [inline]
    slab_alloc_node mm/slub.c:4919 [inline]
    __kmalloc_cache_noprof+0x359/0x440 mm/slub.c:5480
    _kmalloc_noprof include/linux/slab.h:988 [inline]
    _kzalloc_noprof include/linux/slab.h:1309 [inline]
    iopt_alloc_pages.part.0+0x2b/0x210 drivers/iommu/iommufd/pages.c:1375
    iopt_alloc_pages drivers/iommu/iommufd/pages.c:1432 [inline]
    iopt_alloc_file_pages+0x7c/0xf0 drivers/iommu/iommufd/pages.c:1425
    iopt_map_file_pages+0x184/0x1e0 drivers/iommu/iommufd/io_pagetable.c:518
    iommufd_ioas_map_file+0x152/0x2f0 drivers/iommu/iommufd/ioas.c:231
    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: read tcp 127.0.0.1:41845->127.0.0.1:36772: read: connection reset by peer


---
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] [fs?] memory leak in path_openat (4)

[Christian Brauner]

On Wed, Aug 26, 2026 at 07:54:38AM -0700, syzbot wrote:
> Hello,
> 
> syzbot found the following issue on:
> 
> HEAD commit:    26260251022f Merge tag 'livepatching-for-7.3' of git://git..
> git tree:       upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=1196a179580000
> kernel config:  https://syzkaller.appspot.com/x/.config?x=6c1b5958b2d1207f
> dashboard link: https://syzkaller.appspot.com/bug?extid=7666ed2c3d42196bf7e3
> 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=139f7179580000
> 
> Downloadable assets:
> disk image: https://storage.googleapis.com/syzbot-assets/0f75e7622b1f/disk-26260251.raw.xz
> vmlinux: https://storage.googleapis.com/syzbot-assets/2bbff9fd7b60/vmlinux-26260251.xz
> kernel image: https://storage.googleapis.com/syzbot-assets/95d733004907/bzImage-26260251.xz
> 
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+7666ed2c3d42196bf7e3@syzkaller.appspotmail.com

#syz set subsystems: iommufd

This seems to be a reference cycle in iommufd. path_openat() and
alloc_empty_file() is just the place where the file is allocated.

The reproducer does:

  r0 = openat$iommufd(AT_FDCWD, "/dev/iommu", 0, 0)      /* → fd 4 */
  ioctl$IOMMU_IOAS_ALLOC(r0, 0x3b81, {size=0xc})         /* → ioas_id 1 */
  ioctl(r0, 0x3b8f, "2800...0400000000...0010")          /* IOMMU_IOAS_MAP_FILE */

So that last payload can be decoded as:

  iommu_ioas_map_file: size=40, flags=R|W, ioas_id=1, fd=4, start=0, length=0x1000

So fd is r0 itself which is the iommufd fd which is handed back to IOMMU_IOAS_MAP_FILE.

That causes a cycle:

iopt_map_file_pages() does fget(fd) without worrying what it calls it
on. So that does iopt_alloc_file_pages() which takes a long-term reference in pages->file = get_file(file)

The reference is dropped in iopt_release_pages() in fput(pages->file)
from the IOAS teardown. That in turn runs from iommufd_fops_release().

TL;DR:

  struct file(/dev/iommu)->private_data-> ictx->objects->ioas->iopt->area->iopt_pages
          ^                                                                    ^
          |____________________________ get_file() ____________________________|

Closing the fd does nothing. The hex dump shows the same pattern btw:

  - obj1 struct file @ ffff88812811f9c0, obj2 its LSM blob
  - obj3 iommufd_ctx @ ffff88811161cd80, first word = ffff88812811f9c0 → ictx->file is obj1
  - obj5 xa_node, its ->array = ffff88811161cd88 = &ictx->objects
  - obj4 iommufd_object: shortterm_users=1, users=1, type=4, id=1 → the IOAS with ioas_id == 1 from the repro
  - obj6 iopt_pages, kref == 1

Likely caused by f4986a72d6e4 ("iommufd: Add IOMMU_IOAS_MAP_FILE")

Afaic,t, this should either reject based on file->f_op == &iommufd_fops.
But iiuc there's other cycles that can be formed.
For example, via a vfio device fd that's bound to the iommufd. It holds an iommufd_ctx reference via iommufd_ctx_from_fd().
So mapping a bound but unattached vfio fd builds the same cycle.

So probably this should do validation what type of file can actually be
used like shmem and hugepage file.

Re: [syzbot] [fs?] memory leak in path_openat (4)

[syzbot]

> On Wed, Aug 26, 2026 at 07:54:38AM -0700, syzbot wrote:
>> Hello,
>> 
>> syzbot found the following issue on:
>> 
>> HEAD commit:    26260251022f Merge tag 'livepatching-for-7.3' of git://git..
>> git tree:       upstream
>> console output: https://syzkaller.appspot.com/x/log.txt?x=1196a179580000
>> kernel config:  https://syzkaller.appspot.com/x/.config?x=6c1b5958b2d1207f
>> dashboard link: https://syzkaller.appspot.com/bug?extid=7666ed2c3d42196bf7e3
>> 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=139f7179580000
>> 
>> Downloadable assets:
>> disk image: https://storage.googleapis.com/syzbot-assets/0f75e7622b1f/disk-26260251.raw.xz
>> vmlinux: https://storage.googleapis.com/syzbot-assets/2bbff9fd7b60/vmlinux-26260251.xz
>> kernel image: https://storage.googleapis.com/syzbot-assets/95d733004907/bzImage-26260251.xz
>> 
>> IMPORTANT: if you fix the issue, please add the following tag to the commit:
>> Reported-by: syzbot+7666ed2c3d42196bf7e3@syzkaller.appspotmail.com
>
> #syz set subsystems: iommufd

The specified label value is incorrect.
"iommufd" is not among the allowed values.
Please use one of the supported label values.

The following labels are suported:
actionable, missing-backport, no-reminders, prio: {low, normal, high}, subsystems: {..
see below ..}
The list of subsystems: https://syzkaller.appspot.com/upstream/subsystems?all=true

>
> This seems to be a reference cycle in iommufd. path_openat() and
> alloc_empty_file() is just the place where the file is allocated.
>
> The reproducer does:
>
>   r0 = openat$iommufd(AT_FDCWD, "/dev/iommu", 0, 0)      /* → fd 4 */
>   ioctl$IOMMU_IOAS_ALLOC(r0, 0x3b81, {size=0xc})         /* → ioas_id 1 */
>   ioctl(r0, 0x3b8f, "2800...0400000000...0010")          /* IOMMU_IOAS_MAP_FILE */
>
> So that last payload can be decoded as:
>
>   iommu_ioas_map_file: size=40, flags=R|W, ioas_id=1, fd=4, start=0, length=0x1000
>
> So fd is r0 itself which is the iommufd fd which is handed back to IOMMU_IOAS_MAP_FILE.
>
> That causes a cycle:
>
> iopt_map_file_pages() does fget(fd) without worrying what it calls it
> on. So that does iopt_alloc_file_pages() which takes a long-term reference in pages->file = get_file(file)
>
> The reference is dropped in iopt_release_pages() in fput(pages->file)
> from the IOAS teardown. That in turn runs from iommufd_fops_release().
>
> TL;DR:
>
>   struct file(/dev/iommu)->private_data-> ictx->objects->ioas->iopt->area->iopt_pages
>           ^                                                                    ^
>           |____________________________ get_file() ____________________________|
>
> Closing the fd does nothing. The hex dump shows the same pattern btw:
>
>   - obj1 struct file @ ffff88812811f9c0, obj2 its LSM blob
>   - obj3 iommufd_ctx @ ffff88811161cd80, first word = ffff88812811f9c0 → ictx->file is obj1
>   - obj5 xa_node, its ->array = ffff88811161cd88 = &ictx->objects
>   - obj4 iommufd_object: shortterm_users=1, users=1, type=4, id=1 → the IOAS with ioas_id == 1 from the repro
>   - obj6 iopt_pages, kref == 1
>
> Likely caused by f4986a72d6e4 ("iommufd: Add IOMMU_IOAS_MAP_FILE")
>
> Afaic,t, this should either reject based on file->f_op == &iommufd_fops.
> But iiuc there's other cycles that can be formed.
> For example, via a vfio device fd that's bound to the iommufd. It holds an iommufd_ctx reference via iommufd_ctx_from_fd().
> So mapping a bound but unattached vfio fd builds the same cycle.
>
> So probably this should do validation what type of file can actually be
> used like shmem and hugepage file.

Re: [syzbot] [fs?] memory leak in path_openat (4)

[Aleksandr Nogikh]

On Fri, Sep 4, 2026 at 11:18 AM syzbot
<syzbot+7666ed2c3d42196bf7e3@syzkaller.appspotmail.com> wrote:
>
> > On Wed, Aug 26, 2026 at 07:54:38AM -0700, syzbot wrote:
> >> Hello,
> >>
> >> syzbot found the following issue on:
> >>
> >> HEAD commit:    26260251022f Merge tag 'livepatching-for-7.3' of git://git..
> >> git tree:       upstream
> >> console output: https://syzkaller.appspot.com/x/log.txt?x=1196a179580000
> >> kernel config:  https://syzkaller.appspot.com/x/.config?x=6c1b5958b2d1207f
> >> dashboard link: https://syzkaller.appspot.com/bug?extid=7666ed2c3d42196bf7e3
> >> 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=139f7179580000
> >>
> >> Downloadable assets:
> >> disk image: https://storage.googleapis.com/syzbot-assets/0f75e7622b1f/disk-26260251.raw.xz
> >> vmlinux: https://storage.googleapis.com/syzbot-assets/2bbff9fd7b60/vmlinux-26260251.xz
> >> kernel image: https://storage.googleapis.com/syzbot-assets/95d733004907/bzImage-26260251.xz
> >>
> >> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> >> Reported-by: syzbot+7666ed2c3d42196bf7e3@syzkaller.appspotmail.com
> >
> > #syz set subsystems: iommufd
>

#syz set subsystems: iommu

> The specified label value is incorrect.
> "iommufd" is not among the allowed values.
> Please use one of the supported label values.
>
> The following labels are suported:
> actionable, missing-backport, no-reminders, prio: {low, normal, high}, subsystems: {..
> see below ..}
> The list of subsystems: https://syzkaller.appspot.com/upstream/subsystems?all=true
>
> >
> > This seems to be a reference cycle in iommufd. path_openat() and
> > alloc_empty_file() is just the place where the file is allocated.
> >
> > The reproducer does:
> >
> >   r0 = openat$iommufd(AT_FDCWD, "/dev/iommu", 0, 0)      /* → fd 4 */
> >   ioctl$IOMMU_IOAS_ALLOC(r0, 0x3b81, {size=0xc})         /* → ioas_id 1 */
> >   ioctl(r0, 0x3b8f, "2800...0400000000...0010")          /* IOMMU_IOAS_MAP_FILE */
> >
> > So that last payload can be decoded as:
> >
> >   iommu_ioas_map_file: size=40, flags=R|W, ioas_id=1, fd=4, start=0, length=0x1000
> >
> > So fd is r0 itself which is the iommufd fd which is handed back to IOMMU_IOAS_MAP_FILE.
> >
> > That causes a cycle:
> >
> > iopt_map_file_pages() does fget(fd) without worrying what it calls it
> > on. So that does iopt_alloc_file_pages() which takes a long-term reference in pages->file = get_file(file)
> >
> > The reference is dropped in iopt_release_pages() in fput(pages->file)
> > from the IOAS teardown. That in turn runs from iommufd_fops_release().
> >
> > TL;DR:
> >
> >   struct file(/dev/iommu)->private_data-> ictx->objects->ioas->iopt->area->iopt_pages
> >           ^                                                                    ^
> >           |____________________________ get_file() ____________________________|
> >
> > Closing the fd does nothing. The hex dump shows the same pattern btw:
> >
> >   - obj1 struct file @ ffff88812811f9c0, obj2 its LSM blob
> >   - obj3 iommufd_ctx @ ffff88811161cd80, first word = ffff88812811f9c0 → ictx->file is obj1
> >   - obj5 xa_node, its ->array = ffff88811161cd88 = &ictx->objects
> >   - obj4 iommufd_object: shortterm_users=1, users=1, type=4, id=1 → the IOAS with ioas_id == 1 from the repro
> >   - obj6 iopt_pages, kref == 1
> >
> > Likely caused by f4986a72d6e4 ("iommufd: Add IOMMU_IOAS_MAP_FILE")
> >
> > Afaic,t, this should either reject based on file->f_op == &iommufd_fops.
> > But iiuc there's other cycles that can be formed.
> > For example, via a vfio device fd that's bound to the iommufd. It holds an iommufd_ctx reference via iommufd_ctx_from_fd().
> > So mapping a bound but unattached vfio fd builds the same cycle.
> >
> > So probably this should do validation what type of file can actually be
> > used like shmem and hugepage file.
>
> --
> You received this message because you are subscribed to the Google Groups "syzkaller-bugs" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller-bugs+unsubscribe@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/syzkaller-bugs/6a9a8cd1.a011d2ce.399d32.0000.GAE%40google.com.

Re: [syzbot] [fs?] memory leak in path_openat (4)

[Jason Gunthorpe]

On Fri, Sep 04, 2026 at 11:18:02AM +0200, Christian Brauner wrote:
> Closing the fd does nothing. The hex dump shows the same pattern btw:
> 
>   - obj1 struct file @ ffff88812811f9c0, obj2 its LSM blob
>   - obj3 iommufd_ctx @ ffff88811161cd80, first word = ffff88812811f9c0 → ictx->file is obj1
>   - obj5 xa_node, its ->array = ffff88811161cd88 = &ictx->objects
>   - obj4 iommufd_object: shortterm_users=1, users=1, type=4, id=1 → the IOAS with ioas_id == 1 from the repro
>   - obj6 iopt_pages, kref == 1
> 
> Likely caused by f4986a72d6e4 ("iommufd: Add IOMMU_IOAS_MAP_FILE")
> 
> Afaic,t, this should either reject based on file->f_op == &iommufd_fops.
> But iiuc there's other cycles that can be formed.
> For example, via a vfio device fd that's bound to the iommufd. It holds an iommufd_ctx reference via iommufd_ctx_from_fd().
> So mapping a bound but unattached vfio fd builds the same cycle.
> 
> So probably this should do validation what type of file can actually be
> used like shmem and hugepage file.

Oh.. This is a bit of a pain because we rely on memfd_pin_folios() to
determine if the file is acceptable or not. I prefer to keep that
logic contained within the mm side.

The issue is we don't always call memfd_pin_folios() inside the first
system call. A normal user would, but syzkaller has arranged something
a bit weird and out of order.

So we need to figure out some validation to run before the mapping
step..

Thanks,
Jason