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

[Aleksandr Nogikh]

On Fri, Sep 4, 2026 at 11:18 AM syzbot
<syzbot+7666ed2c3d42196bf7e3@xxxxxxxxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxxxx
> >
> > #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@xxxxxxxxxxxxxxxx.
> To view this discussion visit https://groups.google.com/d/msgid/syzkaller-bugs/6a9a8cd1.a011d2ce.399d32.0000.GAE%40google.com.