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

[Jason Gunthorpe <jgg@nvidia.com>]

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