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

[syzbot <syzbot+7666ed2c3d42196bf7e3@syzkaller.appspotmail.com>]

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