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

[Christian Brauner <brauner@kernel.org>]

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.