[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=wi=uOYxfCp+fDT0qoQnvTEb91T25thpZQYw1vkifNVvMQ@mail.gmail.com>
Date: Sat, 30 Nov 2024 10:02:38 -0800
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Christian Brauner <brauner@...nel.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 Sat, 30 Nov 2024 at 04:30, Christian Brauner <brauner@...nel.org> wrote:
>
> What does the smp_load_acquire() pair with?
I'm not sure we have them everywhere, but at least this one at dentry
creation time.
__d_alloc():
/* Make sure we always see the terminating NUL character */
smp_store_release(&dentry->d_name.name, dname); /* ^^^ */
so even at rename time, when we swap the d_name.name pointers
(*without* using a store-release at that time), both of the dentry
names had memory orderings before.
That said, looking at swap_name() at the non-"swap just the pointers"
case, there we do just "memcpy()" the name, and it would probably be
good to update the target d_name.name with a smp_store_release.
In practice, none of this ever matters. Anybody who uses the dentry
name without locking either doesn't care enough (like comm[]) or will
use the sequence number thing to serialize at a much higher level. So
the smp_load_acquire() could probably be a READ_ONCE(), and nobody
would ever see the difference.
Linus
Powered by blists - more mailing lists