From: "Mickaël Salaün" <mic@digikod.net>
To: Al Viro <viro@zeniv.linux.org.uk>
Cc: linux-security-module@vger.kernel.org,
linux-fsdevel@vger.kernel.org,
"Günther Noack" <gnoack@google.com>
Subject: Re: [WTF][landlock] d_is_negative(fd_file(f)->f_path.dentry) ???
Date: Fri, 25 Apr 2025 11:38:37 +0200 [thread overview]
Message-ID: <20250425.aegoh9fieNoh@digikod.net> (raw)
In-Reply-To: <20250424220011.GJ2023217@ZenIV>
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.
prev parent reply other threads:[~2025-04-25 9:38 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-24 22:00 [WTF][landlock] d_is_negative(fd_file(f)->f_path.dentry) ??? Al Viro
2025-04-25 9:38 ` Mickaël Salaün [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250425.aegoh9fieNoh@digikod.net \
--to=mic@digikod.net \
--cc=gnoack@google.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.