From: "Mickaël Salaün" <mic@digikod.net>
To: Jan Kara <jack@suse.cz>
Cc: "Song Liu" <song@kernel.org>,
"Alexei Starovoitov" <alexei.starovoitov@gmail.com>,
"Al Viro" <viro@zeniv.linux.org.uk>, bpf <bpf@vger.kernel.org>,
Linux-Fsdevel <linux-fsdevel@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
"LSM List" <linux-security-module@vger.kernel.org>,
"Kernel Team" <kernel-team@meta.com>,
"Andrii Nakryiko" <andrii@kernel.org>, Eduard <eddyz87@gmail.com>,
"Alexei Starovoitov" <ast@kernel.org>,
"Daniel Borkmann" <daniel@iogearbox.net>,
"Martin KaFai Lau" <martin.lau@linux.dev>,
"Christian Brauner" <brauner@kernel.org>,
"KP Singh" <kpsingh@kernel.org>,
"Matt Bobrowski" <mattbobrowski@google.com>,
"Amir Goldstein" <amir73il@gmail.com>,
repnop@google.com, "Jeff Layton" <jlayton@kernel.org>,
"Josef Bacik" <josef@toxicpanda.com>,
"Günther Noack" <gnoack@google.com>,
"Jann Horn" <jannh@google.com>
Subject: Re: [PATCH bpf-next 3/4] bpf: Introduce path iterator
Date: Tue, 3 Jun 2025 14:49:09 +0200 [thread overview]
Message-ID: <20250603.be1ahteePh8z@digikod.net> (raw)
In-Reply-To: <vumjuw5ha6jtxtadsr5vwjtuneeqfg3vpydciczsn75qdg2ekv@464a4dxtxx27>
On Tue, Jun 03, 2025 at 11:46:22AM +0200, Jan Kara wrote:
> On Fri 30-05-25 16:20:39, Mickaël Salaün wrote:
> > On Thu, May 29, 2025 at 10:05:59AM -0700, Song Liu wrote:
> > > On Thu, May 29, 2025 at 9:57 AM Alexei Starovoitov
> > > <alexei.starovoitov@gmail.com> wrote:
> > > [...]
> > > > >
> > > > > How about we describe this as:
> > > > >
> > > > > Introduce a path iterator, which safely (no crash) walks a struct path.
> > > > > Without malicious parallel modifications, the walk is guaranteed to
> > > > > terminate. The sequence of dentries maybe surprising in presence
> > > > > of parallel directory or mount tree modifications and the iteration may
> > > > > not ever finish in face of parallel malicious directory tree manipulations.
> > > >
> > > > Hold on. If it's really the case then is the landlock susceptible
> > > > to this type of attack already ?
> > > > landlock may infinitely loop in the kernel ?
> > >
> > > I think this only happens if the attacker can modify the mount or
> > > directory tree as fast as the walk, which is probably impossible
> > > in reality.
> >
> > Yes, so this is not an infinite loop but an infinite race between the
> > kernel and a very fast malicious user space process with an infinite
> > number of available nested writable directories, that would also require
> > a filesystem (and a kernel) supporting infinite pathname length.
>
> Well, you definitely don't need infinite pathname length. Example:
>
> Have a dir hierarchy like:
>
> A
> / \
> B C
> |
> D
>
> Start iterating from A/B/D, you climb up to A/B. In parallel atacker does:
>
> mv A/B/ A/C/; mkdir A/B
>
> Now by following parent you get to A/C. In parallel attaker does:
>
> mv A/C/ A/B/; mkdir A/C
>
> And now you are essentially where you've started so this can repeat
> forever.
Yes, this is the scenario I had in mind talking about "infinite race"
(instead of infinite loop). For this to work it will require the
filesystem to support an infinite number of nested directories, but I'm
not sure which FS could be eligible.
Anyway, what would would be the threat model for this infinite race?
>
> As others wrote this particular timing might be hard enough to hit for it
> to not be a practical attack but I would not bet much on somebody not being
> able to invent some variant that works, in particular with BPF iterator.
There might exist corner cases that could be an issue but would the
impact be different than with other kinds of path walk?
What could we do to avoid or limit such issue?
>
> Honza
> --
> Jan Kara <jack@suse.com>
> SUSE Labs, CR
next prev parent reply other threads:[~2025-06-03 12:57 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-28 22:26 [PATCH bpf-next 0/4] bpf " Song Liu
2025-05-28 22:26 ` [PATCH bpf-next 1/4] namei: Introduce new helper function path_parent() Song Liu
2025-05-28 22:26 ` [PATCH bpf-next 2/4] landlock: Use path_parent() Song Liu
2025-05-31 13:51 ` Tingmao Wang
2025-06-02 13:36 ` Song Liu
2025-06-03 0:10 ` Song Liu
2025-06-03 12:47 ` Mickaël Salaün
2025-06-02 17:35 ` Mickaël Salaün
2025-06-02 22:56 ` Tingmao Wang
2025-05-28 22:26 ` [PATCH bpf-next 3/4] bpf: Introduce path iterator Song Liu
2025-05-28 22:37 ` Al Viro
2025-05-29 11:58 ` Jan Kara
2025-05-29 16:53 ` Song Liu
2025-05-29 16:57 ` Alexei Starovoitov
2025-05-29 17:05 ` Song Liu
2025-05-30 14:20 ` Mickaël Salaün
2025-06-02 9:41 ` Christian Brauner
2025-06-03 9:46 ` Jan Kara
2025-06-03 12:49 ` Mickaël Salaün [this message]
2025-06-03 21:13 ` Jan Kara
2025-05-29 17:38 ` Al Viro
2025-05-29 18:00 ` Song Liu
2025-05-29 18:35 ` Al Viro
2025-05-29 19:46 ` Song Liu
2025-05-29 20:15 ` Al Viro
2025-05-29 21:07 ` Song Liu
2025-05-29 21:45 ` Al Viro
2025-05-29 22:13 ` Song Liu
2025-05-29 23:10 ` Al Viro
2025-05-30 0:42 ` Song Liu
2025-05-30 12:20 ` Mickaël Salaün
2025-05-30 18:43 ` Al Viro
2025-05-31 8:39 ` Mickaël Salaün
2025-06-02 9:32 ` Christian Brauner
2025-05-30 18:55 ` Song Liu
2025-05-31 8:40 ` Mickaël Salaün
2025-05-31 14:05 ` Tingmao Wang
2025-06-01 23:33 ` Song Liu
2025-06-04 0:58 ` Tingmao Wang
2025-06-02 9:30 ` Christian Brauner
2025-06-02 9:27 ` Christian Brauner
2025-06-02 13:27 ` Song Liu
2025-06-02 15:40 ` Alexei Starovoitov
2025-06-02 21:39 ` Song Liu
2025-05-28 22:26 ` [PATCH bpf-next 4/4] selftests/bpf: Add tests for bpf " Song Liu
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=20250603.be1ahteePh8z@digikod.net \
--to=mic@digikod.net \
--cc=alexei.starovoitov@gmail.com \
--cc=amir73il@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=brauner@kernel.org \
--cc=daniel@iogearbox.net \
--cc=eddyz87@gmail.com \
--cc=gnoack@google.com \
--cc=jack@suse.cz \
--cc=jannh@google.com \
--cc=jlayton@kernel.org \
--cc=josef@toxicpanda.com \
--cc=kernel-team@meta.com \
--cc=kpsingh@kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=martin.lau@linux.dev \
--cc=mattbobrowski@google.com \
--cc=repnop@google.com \
--cc=song@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®