From: Kees Cook <kees@kernel.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: linux-kernel@vger.kernel.org,
Alexander Viro <viro@zeniv.linux.org.uk>,
Christophe JAILLET <christophe.jaillet@wanadoo.fr>,
"Eric W. Biederman" <ebiederm@xmission.com>,
Nir Lichtman <nir@lichtman.org>,
Tycho Andersen <tandersen@netflix.com>,
Vegard Nossum <vegard.nossum@oracle.com>
Subject: Re: [GIT PULL] execve updates for v6.13-rc1 (take 2)
Date: Wed, 27 Nov 2024 16:53:23 -0800 [thread overview]
Message-ID: <202411271645.04C3508@keescook> (raw)
In-Reply-To: <CAHk-=wgEjs8bwSMSpoyFRiUT=_NEFzF8BXFEvYzVQCu8RD=WmA@mail.gmail.com>
On Tue, Nov 26, 2024 at 12:11:06PM -0800, Linus Torvalds wrote:
> And it looks like __set_task_comm() is actually buggy right now,
> because while we have a comment in linux/sched.h that says
>
> * The strscpy_pad() in __set_task_comm() can ensure that the task comm is
> * always NUL-terminated and zero-padded.
>
> that isn't actually true, because it looks like sized_strscpy()
> actually adds the final NUL at the end. I think that's because Andrew
> only merged a partial patch series.
Oh ew, yes, it looks like it copies the last byte, checks if it was NUL,
and then NULs it if it ran out of space. Ugh.
Before for comm we used strlen + memcpy, and so the trailing NUL was
always present. Grumble grumble. I'll look at your patch and will dig
around and see what works best. I'm on vacation currently, so there will
be some latency...
On a related note, what do you think of using execveat's "pathname"
argument as "comm" if AT_EMPTY_PATH is set? That'll give process
launchers control over comm (which is what they want), and we can keep
the dentry name fallback as proposed too?
-Kees
--
Kees Cook
next prev parent reply other threads:[~2024-11-28 0:53 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-21 14:53 [GIT PULL] execve updates for v6.13-rc1 (take 2) Kees Cook
2024-11-25 23:40 ` Linus Torvalds
2024-11-26 5:09 ` Kees Cook
2024-11-26 20:11 ` Linus Torvalds
2024-11-26 20:12 ` Linus Torvalds
2024-11-28 0:53 ` Kees Cook [this message]
2024-11-28 1:59 ` Linus Torvalds
2024-11-28 2:05 ` Al Viro
2024-11-28 2:24 ` Linus Torvalds
2024-11-29 2:08 ` Kees Cook
2024-11-29 2:43 ` Linus Torvalds
2024-11-29 3:34 ` Al Viro
2024-11-29 4:23 ` Eric W. Biederman
2024-11-29 4:48 ` Al Viro
2024-11-29 17:00 ` Casey Schaufler
2024-11-29 19:33 ` Eric W. Biederman
2024-11-29 4:44 ` Linus Torvalds
2024-11-29 12:41 ` Eric W. Biederman
2024-11-29 21:42 ` Vegard Nossum
2024-11-29 22:54 ` Al Viro
2024-11-30 4:24 ` Linus Torvalds
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=202411271645.04C3508@keescook \
--to=kees@kernel.org \
--cc=christophe.jaillet@wanadoo.fr \
--cc=ebiederm@xmission.com \
--cc=linux-kernel@vger.kernel.org \
--cc=nir@lichtman.org \
--cc=tandersen@netflix.com \
--cc=torvalds@linux-foundation.org \
--cc=vegard.nossum@oracle.com \
--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