From: Christian Brauner <brauner@kernel.org>
To: Jann Horn <jannh@google.com>
Cc: linux-fsdevel@vger.kernel.org,
"Daniel Borkmann" <daniel@iogearbox.net>,
"Kuniyuki Iwashima" <kuniyu@amazon.com>,
"Eric Dumazet" <edumazet@google.com>,
"Oleg Nesterov" <oleg@redhat.com>,
"David S. Miller" <davem@davemloft.net>,
"Alexander Viro" <viro@zeniv.linux.org.uk>,
"Daan De Meyer" <daan.j.demeyer@gmail.com>,
"David Rheinsberg" <david@readahead.eu>,
"Jakub Kicinski" <kuba@kernel.org>, "Jan Kara" <jack@suse.cz>,
"Lennart Poettering" <lennart@poettering.net>,
"Luca Boccassi" <bluca@debian.org>, "Mike Yuan" <me@yhndnzj.com>,
"Paolo Abeni" <pabeni@redhat.com>,
"Simon Horman" <horms@kernel.org>,
"Zbigniew Jędrzejewski-Szmek" <zbyszek@in.waw.pl>,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
linux-security-module@vger.kernel.org,
"Alexander Mikhalitsyn" <alexander@mihalicyn.com>
Subject: Re: [PATCH v7 7/9] coredump: validate socket name as it is written
Date: Fri, 16 May 2025 11:54:31 +0200 [thread overview]
Message-ID: <20250516-planen-radar-2131a4b7d9b1@brauner> (raw)
In-Reply-To: <CAG48ez1wqbOmQMqg6rH4LNjNifHU_WciceO_SQwu8T=tA_KxLw@mail.gmail.com>
On Thu, May 15, 2025 at 10:56:51PM +0200, Jann Horn wrote:
> On Thu, May 15, 2025 at 12:04 AM Christian Brauner <brauner@kernel.org> wrote:
> > In contrast to other parameters written into
> > /proc/sys/kernel/core_pattern that never fail we can validate enabling
> > the new AF_UNIX support. This is obviously racy as hell but it's always
> > been that way.
> >
> > Signed-off-by: Christian Brauner <brauner@kernel.org>
>
> Reviewed-by: Jann Horn <jannh@google.com>
>
> > ---
> > fs/coredump.c | 37 ++++++++++++++++++++++++++++++++++---
> > 1 file changed, 34 insertions(+), 3 deletions(-)
> >
> > diff --git a/fs/coredump.c b/fs/coredump.c
> > index 6ee38e3da108..d4ff08ef03e5 100644
> > --- a/fs/coredump.c
> > +++ b/fs/coredump.c
> > @@ -1228,13 +1228,44 @@ void validate_coredump_safety(void)
> > }
> > }
> >
> > +static inline bool check_coredump_socket(void)
> > +{
> > + if (core_pattern[0] != '@')
> > + return true;
> > +
> > + /*
> > + * Coredump socket must be located in the initial mount
> > + * namespace. Don't give the that impression anything else is
> > + * supported right now.
> > + */
> > + if (current->nsproxy->mnt_ns != init_task.nsproxy->mnt_ns)
> > + return false;
>
> (Ah, dereferencing init_task.nsproxy without locks is safe because
> init_task is actually the boot cpu's swapper/idle task, which never
> switches namespaces, right?)
I would be very worried if it did. It would fsck everyone over that
relies on copying its credentials and assumes that the set of namespaces
is stable.
>
> > + /* Must be an absolute path. */
> > + if (*(core_pattern + 1) != '/')
> > + return false;
> > +
> > + return true;
> > +}
> > +
> > static int proc_dostring_coredump(const struct ctl_table *table, int write,
> > void *buffer, size_t *lenp, loff_t *ppos)
> > {
> > - int error = proc_dostring(table, write, buffer, lenp, ppos);
> > + int error;
> > + ssize_t retval;
> > + char old_core_pattern[CORENAME_MAX_SIZE];
> > +
> > + retval = strscpy(old_core_pattern, core_pattern, CORENAME_MAX_SIZE);
> > +
> > + error = proc_dostring(table, write, buffer, lenp, ppos);
> > + if (error)
> > + return error;
> > + if (!check_coredump_socket()) {
>
> (non-actionable note: This is kiiinda dodgy under
> SYSCTL_WRITES_LEGACY, but I guess we can assume that new users of the
> new coredump socket feature aren't actually going to write the
> coredump path one byte at a time, so I guess it's fine.)
So this is all kinds of broken already imho. Because there's not really
mutual exclusion between multiple writers to such sysctls from what I
remember. Which means that this buffer can be trampled in all kinds of
ways if multiple tasks decide to update it at the same time. That's
super unlikely of course but whatever.
>
> > + strscpy(core_pattern, old_core_pattern, retval + 1);
>
> The third strscpy() argument is semantically supposed to be the
> destination buffer size, not the amount of data to copy. For trivial
> invocations like here, strscpy() actually allows you to leave out the
> third argument.
Eeeeewww, that's really implicit behavior. I can use the destination
buffer size but given that retval will always be smaller than that I
didn't bother but ok. I'll fix that in-tree.
next prev parent reply other threads:[~2025-05-16 9:54 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-14 22:03 [PATCH v7 0/9] coredump: add coredump socket Christian Brauner
2025-05-14 22:03 ` [PATCH v7 1/9] coredump: massage format_corname() Christian Brauner
2025-05-15 13:19 ` Alexander Mikhalitsyn
2025-05-15 13:36 ` Serge E. Hallyn
2025-05-15 20:52 ` Jann Horn
2025-05-14 22:03 ` [PATCH v7 2/9] coredump: massage do_coredump() Christian Brauner
2025-05-15 13:21 ` Alexander Mikhalitsyn
2025-05-15 20:52 ` Jann Horn
2025-05-14 22:03 ` [PATCH v7 3/9] coredump: reflow dump helpers a little Christian Brauner
2025-05-15 13:22 ` Alexander Mikhalitsyn
2025-05-15 20:53 ` Jann Horn
2025-05-14 22:03 ` [PATCH v7 4/9] coredump: add coredump socket Christian Brauner
2025-05-15 13:47 ` Alexander Mikhalitsyn
2025-05-16 8:30 ` Christian Brauner
2025-05-15 17:00 ` Kuniyuki Iwashima
2025-05-15 20:52 ` Jann Horn
2025-05-15 21:04 ` Kuniyuki Iwashima
2025-05-16 10:14 ` Christian Brauner
2025-05-15 20:54 ` Jann Horn
2025-05-15 21:15 ` Kuniyuki Iwashima
2025-05-16 10:09 ` Christian Brauner
2025-05-16 10:20 ` Christian Brauner
2025-05-14 22:03 ` [PATCH v7 5/9] pidfs, coredump: add PIDFD_INFO_COREDUMP Christian Brauner
2025-05-15 14:08 ` Alexander Mikhalitsyn
2025-05-15 20:56 ` Jann Horn
2025-05-15 21:37 ` Jann Horn
2025-05-16 10:34 ` Christian Brauner
2025-05-16 14:26 ` Jann Horn
2025-05-14 22:03 ` [PATCH v7 6/9] coredump: show supported coredump modes Christian Brauner
2025-05-15 13:56 ` Alexander Mikhalitsyn
2025-05-15 20:56 ` Jann Horn
2025-05-14 22:03 ` [PATCH v7 7/9] coredump: validate socket name as it is written Christian Brauner
2025-05-15 14:03 ` Alexander Mikhalitsyn
2025-05-15 20:56 ` Jann Horn
2025-05-16 9:54 ` Christian Brauner [this message]
2025-05-16 13:29 ` Christian Brauner
2025-05-14 22:03 ` [PATCH v7 8/9] selftests/pidfd: add PIDFD_INFO_COREDUMP infrastructure Christian Brauner
2025-05-15 14:35 ` Alexander Mikhalitsyn
2025-05-14 22:03 ` [PATCH v7 9/9] selftests/coredump: add tests for AF_UNIX coredumps Christian Brauner
2025-05-15 14:37 ` Alexander Mikhalitsyn
2025-05-14 22:38 ` [PATCH v7 0/9] coredump: add coredump socket Luca Boccassi
2025-05-15 9:17 ` Christian Brauner
2025-05-15 9:26 ` Lennart Poettering
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=20250516-planen-radar-2131a4b7d9b1@brauner \
--to=brauner@kernel.org \
--cc=alexander@mihalicyn.com \
--cc=bluca@debian.org \
--cc=daan.j.demeyer@gmail.com \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=david@readahead.eu \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=jack@suse.cz \
--cc=jannh@google.com \
--cc=kuba@kernel.org \
--cc=kuniyu@amazon.com \
--cc=lennart@poettering.net \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=me@yhndnzj.com \
--cc=netdev@vger.kernel.org \
--cc=oleg@redhat.com \
--cc=pabeni@redhat.com \
--cc=viro@zeniv.linux.org.uk \
--cc=zbyszek@in.waw.pl \
/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