Re: v7.0-rc1, name_to_handle_at(..., AT_EMPTY_PATH)

[Al Viro <viro@zeniv.linux.org.uk>]

On Fri, Feb 27, 2026 at 06:48:04PM +0000, Al Viro wrote:
> On Sat, Feb 28, 2026 at 12:41:04AM +0900, hooanon05g@gmail.com wrote:
> > Al Viro:
> > > This
> > > struct filename *getname_uflags(const char __user *filename, int uflags)
> > > {
> > >         int flags = (uflags & AT_EMPTY_PATH) ? LOOKUP_EMPTY : 0;
> > >
> > > 	return getname_flags(filename, flags);
> > > }
> > > is where AT_EMPTY_PATH is handled; could you check the arguuments it's getting
> > > in your reproducer and argument passed to getname_flags()?
> > 
> > getname_flags() is not a problem.
> > For me, the problem looks that LOOKUP_EMPTY is NOT passed to
> > path_lookupat().
> 
> Could you please show me a single place in path_lookupat() where we would
> check for for LOOKUP_EMPTY?
> 
> The last point where LOOKUP_EMPTY (or AT_EMPTY_PATH) matters is (and had
> always been) getname_flags(); pathname resolution proper doesn't care.
> 
> In theory some out-of-tree filesystem might have been playing silly
> buggers with LOOKUP_EMPTY in its ->d_revalidate(); there's no good
> reason for doing so, though, and none of the in-tree filesystems had
> ever tried to pull that off.

To elaborate a bit: LOOKUP_EMPTY has ever had only one purpose - to tell
getname...() that empty pathname is not to be rejected.  This is _all_
- e.g. a combination of LOOKUP_EMPTY with non-empty pathname has always
been possible.  It simply does not carry any useful information past
that check on pathname import.

Nothing in pathname resolution checks it; of the few filesystem methods
that might see something of nd->flags, only ->d{_weak}_revalidate() would
have a chance to see that one for an empty pathname (no components to
look up, obviously).  And considering how uninformative LOOKUP_EMPTY would
be for that method... not a single in-tree instance had bothered to check.

Note that combination of AT_EMPTY_PATH with a non-empty pathname
has always been legitimate, and it would better behave exactly
like the call the same non-empty pathname and AT_EMPTY_PATH
removed from the flags.  So if LOOKUP_EMPTY changes behaviour of
->d_weak_revalidate()/->d_revalidate(), it's almost certainly a bug.

Is your testcase on the mainline kernel?  If not, is there an out-of-tree
filesystem involved?  Are there any kprobes/bpf programs/etc. stuck
into the guts of fs/namei.c?  struct nameidata shouldn't be even visible
to any of those, but...