[WTF][landlock] d_is_negative(fd_file(f)->f_path.dentry) ???

[WTF][landlock] d_is_negative(fd_file(f)->f_path.dentry) ???

[Al Viro]

static int get_path_from_fd(const s32 fd, struct path *const path)
{
...
        if ((fd_file(f)->f_op == &ruleset_fops) ||
            (fd_file(f)->f_path.mnt->mnt_flags & MNT_INTERNAL) ||
            (fd_file(f)->f_path.dentry->d_sb->s_flags & SB_NOUSER) ||
            d_is_negative(fd_file(f)->f_path.dentry) ||
            IS_PRIVATE(d_backing_inode(fd_file(f)->f_path.dentry)))
                return -EBADFD;

	Folks, could somebody explain how exactly can an opened file
come to have a _negative_ dentry?  And if you have found a way for that
to happen, why didn't you report the arseloads of NULL pointer dereference
bugs that would expose, along with assorted memory corruptors, etc.?

	Normally I would just quietly rip the bogus check out, but on
the off-chance that somebody _has_ found a bug that would cause that,
I would prefer to check with those who had added the check in the first
place.

Re: [WTF][landlock] d_is_negative(fd_file(f)->f_path.dentry) ???

[Mickaël Salaün]

On Thu, Apr 24, 2025 at 11:00:11PM +0100, Al Viro wrote:
> 
> static int get_path_from_fd(const s32 fd, struct path *const path)
> {
> ...
>         if ((fd_file(f)->f_op == &ruleset_fops) ||
>             (fd_file(f)->f_path.mnt->mnt_flags & MNT_INTERNAL) ||
>             (fd_file(f)->f_path.dentry->d_sb->s_flags & SB_NOUSER) ||
>             d_is_negative(fd_file(f)->f_path.dentry) ||
>             IS_PRIVATE(d_backing_inode(fd_file(f)->f_path.dentry)))
>                 return -EBADFD;
> 
> 	Folks, could somebody explain how exactly can an opened file
> come to have a _negative_ dentry?  And if you have found a way for that
> to happen, why didn't you report the arseloads of NULL pointer dereference
> bugs that would expose, along with assorted memory corruptors, etc.?

I wasn't sure if it was possible or not (for any possible FD), and as a
preventive approach I preferred to check that before dereferencing the
inode.

> 
> 	Normally I would just quietly rip the bogus check out, but on
> the off-chance that somebody _has_ found a bug that would cause that,
> I would prefer to check with those who had added the check in the first
> place.

Thanks for the heads up.  I don't have a specific scenario in mind, feel
free to remove this check if it looks overcautious to you.