Re: [PATCH] fanotify: report names longer than NAME_MAX

[Jan Kara]

 On Tue 06-10-26 15:33:20, Amir Goldstein wrote:
> On Sat, Sep 26, 2026 at 4:08 AM Matthias Goergens
> <matthias.goergens@xxxxxxxxx> wrote:
> >
> > fanotify keeps the length of a reported name in a u8, so it drops any
> > name longer than NAME_MAX and warns:
> >
> >   WARNING: fs/notify/fanotify/fanotify.h:217 at fanotify_handle_event+0x2e82/0x39f0
> >
> > Such names are legitimate on some filesystems.  vfat mounted with utf8
> > takes up to 255 UTF-16 characters, which are up to 765 bytes of UTF-8,
> > and FUSE accepts names up to PATH_MAX - 1.  readdir() and inotify report
> > them in full.  fanotify sends the event without the name, and for
> > FAN_RENAME it trips a second warning in copy_fid_info_to_user(), after
> > which read() fails with EFAULT and the event is lost.
> >
> > When syzbot hit this, Jan suggested accommodating names up to PATH_MAX
> > [1], the limit readdir() already applies to a name
> > (verify_dirent_name()).  Store the name lengths as u16, which keeps
> > struct fanotify_info at 8 bytes, and drop without a warning only names
> > of PATH_MAX bytes or more, which no path can refer to.  An event with
> > such a name can exceed a page, so allocate name events with kvmalloc(),
> > as Jan also suggested.  Names up to NAME_MAX are reported exactly as
> > before, and the record format is unchanged: an event with a long name is
> > just longer.
> >
> > Link: https://lore.kernel.org/all/20241112115059.ecvomkalee5m4i4i@quack3/ [1]
> > Fixes: 2d9374f09513 ("fanotify: use macros to get the offset to fanotify_info buffer")
> > Cc: stable@xxxxxxxxxxxxxxx
> > Signed-off-by: Matthias Goergens <matthias.goergens@xxxxxxxxx>
> > ---
> >
> > Tested in a VM with KASAN, lockdep and kmemleak: on vfat (utf8), names
> > of 258 to 765 bytes now arrive with their name, including FAN_RENAME,
> > for root and for an unprivileged watcher; FUSE names up to 4095 bytes
> > likewise, also a FAN_RENAME between two of them.  With kvmalloc()'s
> > kmalloc() attempt forced to fail, the events arrive intact from vmalloc.
> > No warnings.  The LTP fanotify and inotify tests give the same results
> > as before (fanotify20 skipped in both).
> >
> > 5.15.y fails the same way (the same warnings and EFAULT on 5.15.221),
> > and the patch applies there and fixes it.
> >
> > Honza, on the msdos report [2] you pointed at the filesystem, and msdos
> > now rejects such names (9d7ed813ee5f).  vfat cannot do the same without
> > making files that other systems wrote unreachable, and FUSE allows them
> > by design.
> >
> > [2] https://lore.kernel.org/all/3kzvlb3wpzbg6k6ttzp6rh2cfmz3hmmmlisgxjn5u4xmaaqibm@qkre7flkhejl/

...

> The fix for name_len < PATH_MAX looks good, but since you dealt with the
> the unexpected case of name_len > PATH_MAX more gracefully on event record
> time (empty name) I would rather that we treat it gracefully only on read() time
> and just report the event with no name instead of potentially breaking
> the read()
> of other events in the queue.

Guys, I wouldn't overengineer this. getname() never lets any path >= PATH_MAX
into the kernel, let alone individual dentries. So there's no
way this happens and the less code that pretends this can happen the
better. I guess I'm OK with checking *and loudly complaining* when
allocating such event but that's it. So what I plan to merge is the
attached patch.

								Honza
-- 
Jan Kara <jack@xxxxxxxx>
SUSE Labs, CR