public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Eric W. Biederman" <ebiederm@xmission.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Al Viro <viro@zeniv.linux.org.uk>,  Kees Cook <kees@kernel.org>,
	linux-kernel@vger.kernel.org,
	 Christophe JAILLET <christophe.jaillet@wanadoo.fr>,
	 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: Fri, 29 Nov 2024 06:41:11 -0600	[thread overview]
Message-ID: <874j3qnrfc.fsf@email.froward.int.ebiederm.org> (raw)
In-Reply-To: <CAHk-=whi+OgKMXoPQ+48i=_Cu_Yb5_QCv9U9+Wpg0-GumHZSXg@mail.gmail.com> (Linus Torvalds's message of "Thu, 28 Nov 2024 20:44:11 -0800")

Linus Torvalds <torvalds@linux-foundation.org> writes:

> On Thu, 28 Nov 2024 at 19:34, Al Viro <viro@zeniv.linux.org.uk> wrote:
>>
>> Just one thing - IMO we want to use the relative pathname when it's
>> not empty.  Even in execveat()
>
> Oh, absolutely agreed.
>
> Good catch, because yes, I messed that part up in my suggested patch at
>
>    https://lore.kernel.org/all/CAHk-=wjF_09Z6vu7f8UAbQVDDoHnd-j391YpUxmBPLD=SKbKtQ@mail.gmail.com/
>
> which did this dentry name thing for anything that used a base fd, but
> yes, as you say, it should only do it when there is no name at all.
>
> So instead of basing it (incorrectly) on that existing
>
>         if (fd == AT_FDCWD || filename->name[0] == '/') {
>
> test, the logic should probably look something like
>
>         if (!filename->name[0]) {
>                 rcu_read_lock();
>                 strscpy(bprm->comm,
> smp_load_acquire(&file->f_path.dentry->d_name.name));
>                 rcu_read_unlock();
>         } else
>                 strscpy(bprm->comm, kbasename(filename->name));
>
> and it probably wouldn't be a bad idea to separate this out to be a
> helper function that just does this one thing.

Yes.

It probably makes sense to change __set_task_comm
to something simple like:

void __set_task_comm(struct task_struct *tsk, const char *buf[TASK_COMM_LEN], bool exec)
{
	trace_task_rename(tsk, buf);
        memcpy(tsk->comm, buf, TASK_COMM_LEN);
	perf_event_comm(tsk, exec);
}

There are only 6 callers of set_task_comm and __set_task_comm and they
are straight forward to verify that they pass in a TASK_COMM_LEN bytes
that are already initialized.  With the bytes already properly
initialized just copying them looks like it is as safe as anything else
when it comes to races.

The callers need to be tweaked a little to meet that condition
something like:

diff --git a/io_uring/io-wq.c b/io_uring/io-wq.c
index a38f36b68060..5d0928f37471 100644
--- a/io_uring/io-wq.c
+++ b/io_uring/io-wq.c
@@ -634,7 +634,7 @@ static int io_wq_worker(void *data)
	struct io_wq_acct *acct = io_wq_get_acct(worker);
	struct io_wq *wq = worker->wq;
	bool exit_mask = false, last_timeout = false;
-	char buf[TASK_COMM_LEN];
+	char buf[TASK_COMM_LEN] = {};
 
	set_mask_bits(&worker->flags, 0,
		      BIT(IO_WORKER_F_UP) | BIT(IO_WORKER_F_RUNNING));
diff --git a/io_uring/sqpoll.c b/io_uring/sqpoll.c
index 6df5e649c413..701390bbb303 100644
--- a/io_uring/sqpoll.c
+++ b/io_uring/sqpoll.c
@@ -264,7 +264,7 @@ static int io_sq_thread(void *data)
	struct io_ring_ctx *ctx;
	struct rusage start;
	unsigned long timeout = 0;
-	char buf[TASK_COMM_LEN];
+	char buf[TASK_COMM_LEN] = {};
	DEFINE_WAIT(wait);
 
	/* offload context creation failed, just exit */
diff --git a/kernel/kthread.c b/kernel/kthread.c
index a5ac612b1609..2b126835d728 100644
--- a/kernel/kthread.c
+++ b/kernel/kthread.c
@@ -738,10 +738,11 @@ EXPORT_SYMBOL(kthread_stop_put);
 
 int kthreadd(void *unused)
 {
+	static const char comm[TASK_COMM_LEN] = "kthreadd";
	struct task_struct *tsk = current;
 
	/* Setup a clean context for our children to inherit. */
-	set_task_comm(tsk, "kthreadd");
+	set_task_comm(tsk, comm);
	ignore_signals(tsk);
	set_cpus_allowed_ptr(tsk, housekeeping_cpumask(HK_TYPE_KTHREAD));
	set_mems_allowed(node_states[N_MEMORY]);


Eric

  reply	other threads:[~2024-11-29 12:41 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
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 [this message]
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=874j3qnrfc.fsf@email.froward.int.ebiederm.org \
    --to=ebiederm@xmission.com \
    --cc=christophe.jaillet@wanadoo.fr \
    --cc=kees@kernel.org \
    --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