[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20241201-seerosen-opern-8dfda1f79c50@brauner>
Date: Sun, 1 Dec 2024 19:37:22 +0100
From: Christian Brauner <brauner@...nel.org>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Kees Cook <kees@...nel.org>, Al Viro <viro@...iv.linux.org.uk>,
Zbigniew Jędrzejewski-Szmek <zbyszek@...waw.pl>, Tycho Andersen <tandersen@...flix.com>,
Aleksa Sarai <cyphar@...har.com>, Eric Biederman <ebiederm@...ssion.com>, Jan Kara <jack@...e.cz>,
linux-mm@...ck.org, linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-hardening@...r.kernel.org
Subject: Re: [PATCH] exec: fix up /proc/pid/comm in the
execveat(AT_EMPTY_PATH) case
On Sun, Dec 01, 2024 at 08:54:41AM -0800, Linus Torvalds wrote:
> On Sun, 1 Dec 2024 at 06:17, Christian Brauner <brauner@...nel.org> wrote:
> >
> > /*
> > * Hold rcu lock to keep the name from being freed behind our back.
> > * Use cquire semantics to make sure the terminating NUL from
> > * __d_alloc() is seen.
> > *
> > * Note, we're deliberately sloppy here. We don't need to care about
> > * detecting a concurrent rename and just want a sensible name.
> > */
>
> Sure. Note that even "sensible" isn't truly guaranteed in theory,
> since a concurrent rename could be doing a "memcpy()" into the
> dentry->d_name.name area at the same time on another CPU.
Yeah, I saw, if the dname.name assignment is reorded to happen before
the memcpy() afaict. Anyway, it's not that important especially since
PR_SET_MM_MAP puts comm, auxv etc. fully under user control anyway.
Powered by blists - more mailing lists