From: sashiko-bot@kernel.org
To: "André Almeida" <andrealmeid@igalia.com>,
"Peter Zijlstra" <peterz@infradead.org>,
"Juri Lelli" <juri.lelli@redhat.com>,
"Vincent Guittot" <vincent.guittot@linaro.org>,
"Steven Rostedt" <rostedt@goodmis.org>,
"Christian Brauner" <brauner@kernel.org>,
"Kees Cook" <kees@kernel.org>, "Shuah Khan" <shuah@kernel.org>,
willy@infradead.org, mathieu.desnoyers@efficios.com,
"David Laight" <david.laight.linux@gmail.com>,
"Linus Torvalds" <torvalds@linux-foundation.org>,
akpm@linux-foundation.org, "Yafang Shao" <laoar.shao@gmail.com>,
andrii.nakryiko@gmail.com, arnaldo.melo@gmail.com,
"Petr Mladek" <pmladek@suse.com>
Cc: kernel-dev@igalia.com, linux-mm@kvack.org,
linux-trace-kernel@vger.kernel.org
Subject: Re: [PATCH v8 5/6] prctl: Add support for long user thread names
Date: Sat, 31 Oct 2026 21:39:27 +0000 [thread overview]
Message-ID: <sashiko-outbox-192182@kernel.org> (raw)
In-Reply-To: <20261030-tonyk-long_name-v8-5-c9b030332254@igalia.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] prctl: missing arg validation and buffer size UAPI in PR_{SET,GET}_EXT_NAME
--
commit d86849bc61de6aa30e004f18202851c2e72d0d41
Author: André Almeida <andrealmeid@igalia.com>
prctl: Add support for long user thread names
This commit adds the PR_SET_EXT_NAME and PR_GET_EXT_NAME prctl() options to
support getting and setting extended user thread names up to
TASK_COMM_EXT_LEN bytes.
> diff --git a/include/uapi/linux/prctl.h b/include/uapi/linux/prctl.h
> index b6ec6f6937195..a07f8edadd652 100644
> --- a/include/uapi/linux/prctl.h
> +++ b/include/uapi/linux/prctl.h
> @@ -56,6 +56,9 @@
> #define PR_SET_NAME 15 /* Set process name */
> #define PR_GET_NAME 16 /* Get process name */
>
> +#define PR_SET_EXT_NAME 17 /* Set extended process name */
> +#define PR_GET_EXT_NAME 18 /* Get extended process name */
> +
> /* Get/set process endian */
> #define PR_GET_ENDIAN 19
> #define PR_SET_ENDIAN 20
> diff --git a/kernel/sys.c b/kernel/sys.c
> index 6a72c7e644e70..fc9e3c5a91353 100644
> --- a/kernel/sys.c
> +++ b/kernel/sys.c
[ ... ]
> @@ -2616,6 +2616,19 @@ SYSCALL_DEFINE5(prctl, int, option, unsigned long, arg2, unsigned long, arg3,
> if (copy_to_user((char __user *)arg2, comm, TASK_COMM_LEN))
> return -EFAULT;
> break;
> + case PR_SET_EXT_NAME:
> + comm[TASK_COMM_EXT_LEN - 1] = 0;
> + if (strncpy_from_user(comm, (char __user *)arg2,
> + TASK_COMM_EXT_LEN - 1) < 0)
> + return -EFAULT;
> + set_task_comm(me, comm);
> + proc_comm_connector(me);
> + break;
> + case PR_GET_EXT_NAME:
> + strscpy_pad(comm, me->comm, TASK_COMM_EXT_LEN);
> + if (copy_to_user((char __user *)arg2, comm, TASK_COMM_EXT_LEN))
> + return -EFAULT;
> + break;
[Severity: Medium]
Should PR_SET_EXT_NAME and PR_GET_EXT_NAME in SYSCALL_DEFINE5(prctl) validate
that the unused arguments (arg3, arg4, and arg5) are zero and return -EINVAL
otherwise? Because libc's prctl() wrapper is variadic, 2-argument calls from
userspace can pass arbitrary register values in arg3..arg5, which prevents
extending these options with flags or length parameters in the future.
In addition, PR_GET_EXT_NAME unconditionally copies TASK_COMM_EXT_LEN (64)
bytes to the userspace buffer at arg2, but TASK_COMM_EXT_LEN is only defined
in include/linux/sched.h and is not exposed in include/uapi/linux/prctl.h:
include/linux/sched.h:
enum {
TASK_COMM_LEN = 16,
TASK_COMM_EXT_LEN = 64,
};
Without a UAPI constant or a buffer size argument in PR_GET_EXT_NAME, could a
userspace caller passing a smaller buffer (or passing a buffer length in arg3)
have 64 bytes written past the end of its buffer, or break if
TASK_COMM_EXT_LEN is ever increased?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261030-tonyk-long_name-v8-0-c9b030332254@igalia.com?part=5
next prev parent reply other threads:[~2026-10-31 21:39 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-30 21:38 [PATCH v8 0/6] sched: Add support for long task name André Almeida
2026-10-30 21:38 ` [PATCH v8 1/6] treewide: Get rid of get_task_comm() André Almeida
2026-10-30 21:38 ` [PATCH v8 2/6] treewide: Replace memcpy(..., current->comm) with copy_task_comm() André Almeida
2026-10-30 22:34 ` David Laight
2026-10-31 14:30 ` Steven Rostedt
2026-10-30 21:38 ` [PATCH v8 3/6] lib/string_kunit: Add test for copy_task_comm() André Almeida
2026-10-31 21:39 ` sashiko-bot
2026-10-30 21:38 ` [PATCH v8 4/6] sched: Extend task command name with TASK_COMM_EXT_LEN André Almeida
2026-10-31 21:39 ` sashiko-bot
2026-11-01 0:10 ` kernel test robot
2026-10-30 21:38 ` [PATCH v8 5/6] prctl: Add support for long user thread names André Almeida
2026-10-31 21:39 ` sashiko-bot [this message]
2026-10-30 21:38 ` [PATCH v8 6/6] selftests: prctl: Add test for long " André Almeida
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=sashiko-outbox-192182@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=andrealmeid@igalia.com \
--cc=andrii.nakryiko@gmail.com \
--cc=arnaldo.melo@gmail.com \
--cc=brauner@kernel.org \
--cc=david.laight.linux@gmail.com \
--cc=juri.lelli@redhat.com \
--cc=kees@kernel.org \
--cc=kernel-dev@igalia.com \
--cc=laoar.shao@gmail.com \
--cc=linux-mm@kvack.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=peterz@infradead.org \
--cc=pmladek@suse.com \
--cc=rostedt@goodmis.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=shuah@kernel.org \
--cc=torvalds@linux-foundation.org \
--cc=vincent.guittot@linaro.org \
--cc=willy@infradead.org \
/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