From: Al Viro <viro@zeniv.linux.org.uk>
To: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Cc: Wenbo Zhang <ethercflow@gmail.com>,
bpf@vger.kernel.org, ast@kernel.org.com, daniel@iogearbox.net,
yhs@fb.com, andrii.nakryiko@gmail.com, netdev@vger.kernel.org,
linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH bpf-next v10 1/2] bpf: add new helper get_file_path for mapping a file descriptor to a pathname
Date: Sat, 23 Nov 2019 04:51:51 +0000 [thread overview]
Message-ID: <20191123045151.GH26530@ZenIV.linux.org.uk> (raw)
In-Reply-To: <20191123031826.j2dj7mzto57ml6pr@ast-mbp.dhcp.thefacebook.com>
On Fri, Nov 22, 2019 at 07:18:28PM -0800, Alexei Starovoitov wrote:
> > + f = fget_raw(fd);
> > + if (!f)
> > + goto error;
> > +
> > + /* For unmountable pseudo filesystem, it seems to have no meaning
> > + * to get their fake paths as they don't have path, and to be no
> > + * way to validate this function pointer can be always safe to call
> > + * in the current context.
> > + */
> > + if (f->f_path.dentry->d_op && f->f_path.dentry->d_op->d_dname)
> > + return -EINVAL;
An obvious leak here, BTW.
Anyway, what could that be used for? I mean, if you want to check
something about syscall arguments, that's an unfixably racy way to go.
Descriptor table can be a shared data structure, and two consequent
fdget() on the same number can bloody well yield completely unrelated
struct file references.
IOW, anything that does descriptor -> struct file * translation more than
once is an instant TOCTOU suspect. In this particular case, the function
will produce a pathname of something that was once reachable via descriptor
with this number; quite possibly never before that function had been called
_and_ not once after it has returned.
next prev parent reply other threads:[~2019-11-23 4:51 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-19 13:27 [PATCH bpf-next v10 0/2] bpf: adding get_file_path helper Wenbo Zhang
2019-11-19 13:27 ` [PATCH bpf-next v10 1/2] bpf: add new helper get_file_path for mapping a file descriptor to a pathname Wenbo Zhang
2019-11-23 3:18 ` Alexei Starovoitov
2019-11-23 4:43 ` Al Viro
2019-11-23 4:51 ` Al Viro [this message]
2019-11-23 5:19 ` Alexei Starovoitov
2019-11-23 5:35 ` Al Viro
2019-11-23 6:04 ` Alexei Starovoitov
2019-12-13 19:51 ` Brendan Gregg
2019-12-05 4:20 ` [PATCH bpf-next v11 0/2] bpf: adding get_file_path helper Wenbo Zhang
2019-12-05 4:20 ` [PATCH bpf-next v11 1/2] bpf: add new helper get_file_path for mapping a file descriptor to a pathname Wenbo Zhang
2019-12-05 7:19 ` Alexei Starovoitov
2019-12-05 9:47 ` Wenbo Zhang
2019-12-15 4:01 ` [PATCH bpf-next v12 0/2] bpf: adding get_file_path helper Wenbo Zhang
2019-12-15 4:01 ` [PATCH bpf-next v12 1/2] bpf: add new helper get_file_path for mapping a file descriptor to a pathname Wenbo Zhang
2019-12-15 16:05 ` Yonghong Song
2019-12-17 6:26 ` Wenbo Zhang
2019-12-17 6:33 ` Yonghong Song
2019-12-15 16:10 ` Yonghong Song
2019-12-17 6:27 ` Wenbo Zhang
2019-12-16 22:09 ` Brendan Gregg
2019-12-17 4:05 ` Wenbo Zhang
2019-12-17 9:47 ` [PATCH bpf-next v13 0/2] bpf: adding get_fd_path helper Wenbo Zhang
2019-12-17 9:47 ` [PATCH bpf-next v13 1/2] bpf: add new helper get_fd_path for mapping a file descriptor to a pathname Wenbo Zhang
2019-12-17 16:29 ` Yonghong Song
2019-12-17 19:39 ` Daniel Borkmann
2019-12-18 0:11 ` Wenbo Zhang
2019-12-18 0:06 ` Wenbo Zhang
2019-12-18 0:56 ` [PATCH bpf-next v14 0/2] bpf: adding get_fd_path helper Wenbo Zhang
2019-12-18 0:56 ` [PATCH bpf-next v14 1/2] bpf: add new helper get_fd_path for mapping a file descriptor to a pathname Wenbo Zhang
2019-12-18 3:27 ` Yonghong Song
2019-12-19 16:14 ` Daniel Borkmann
2019-12-20 3:35 ` Wenbo Zhang
2020-01-16 8:59 ` Jiri Olsa
2020-02-10 4:43 ` Brendan Gregg
2020-02-11 0:01 ` Daniel Borkmann
2020-02-12 15:21 ` Jiri Olsa
2020-06-01 14:17 ` Wenbo Zhang
2020-06-01 16:38 ` Alexei Starovoitov
2020-06-02 3:04 ` Wenbo Zhang
2020-06-02 8:14 ` Jiri Olsa
2019-12-18 0:56 ` [PATCH bpf-next v14 2/2] selftests/bpf: test for bpf_get_fd_path() from tracepoint Wenbo Zhang
2019-12-18 3:27 ` Yonghong Song
2019-12-17 9:47 ` [PATCH bpf-next v13 " Wenbo Zhang
2019-12-17 16:32 ` Yonghong Song
2019-12-15 4:01 ` [PATCH bpf-next v12 2/2] selftests/bpf: test for bpf_get_file_path() " Wenbo Zhang
2019-12-15 16:24 ` Yonghong Song
2019-12-17 4:01 ` Wenbo Zhang
2019-12-17 4:13 ` Yonghong Song
2019-12-17 9:44 ` Wenbo Zhang
2019-12-05 4:20 ` [PATCH bpf-next v11 " Wenbo Zhang
2019-11-19 13:27 ` [PATCH bpf-next v10 " Wenbo Zhang
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=20191123045151.GH26530@ZenIV.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=alexei.starovoitov@gmail.com \
--cc=andrii.nakryiko@gmail.com \
--cc=ast@kernel.org.com \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=ethercflow@gmail.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=yhs@fb.com \
/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.