On Thu, Aug 21, 2025 at 03:51:51PM +0530, Bhupesh wrote:
> As Linus mentioned in [1], currently we have several memcpy() use-cases
> which use 'current->comm' to copy the task name over to local copies.
> For an example:
>
> ...
> char comm[TASK_COMM_LEN];
> memcpy(comm, current->comm, TASK_COMM_LEN);
> ...
>
> These should be rather calling a wrappper like "get_task_array()",
> which is implemented as:
>
> static __always_inline void
> __cstr_array_copy(char *dst,
> const char *src, __kernel_size_t size)
> {
> memcpy(dst, src, size);
> dst[size] = 0;
> }
>
> #define get_task_array(dst,src) \
> __cstr_array_copy(dst, src, __must_be_array(dst))
>
> The relevant 'memcpy()' users were identified using the following search
> pattern:
> $ git grep 'memcpy.*->comm\>'
>
> Link:
> https://lore.kernel.org/all/CAHk-=wi5c=_-FBGo_88CowJd_F-Gi6Ud9d=talm65ren7yj...@mail.gmail.com/
> #1
>
> Signed-off-by: Bhupesh <bhup...@igalia.com>
> ---
> include/linux/coredump.h | 2 +-
> include/linux/sched.h | 32 +++++++++++++++++++
> include/linux/tracepoint.h | 4 +--
> include/trace/events/block.h | 10 +++---
> include/trace/events/oom.h | 2 +-
> include/trace/events/osnoise.h | 2 +-
> include/trace/events/sched.h | 13 ++++----
> include/trace/events/signal.h | 2 +-
> include/trace/events/task.h | 4 +--
> tools/bpf/bpftool/pids.c | 6 ++--
> .../bpf/test_kmods/bpf_testmod-events.h | 2 +-
> 11 files changed, 54 insertions(+), 25 deletions(-)
>
> diff --git a/include/linux/coredump.h b/include/linux/coredump.h
> index 68861da4cf7c..bcee0afc5eaf 100644
> --- a/include/linux/coredump.h
> +++ b/include/linux/coredump.h
> @@ -54,7 +54,7 @@ extern void vfs_coredump(const kernel_siginfo_t *siginfo);
> do { \
> char comm[TASK_COMM_LEN]; \
> /* This will always be NUL terminated. */ \
> - memcpy(comm, current->comm, sizeof(comm)); \
> + get_task_array(comm, current->comm); \
> printk_ratelimited(Level "coredump: %d(%*pE): " Format "\n",
> \
> task_tgid_vnr(current), (int)strlen(comm), comm,
> ##__VA_ARGS__); \
> } while (0) \
> diff --git a/include/linux/sched.h b/include/linux/sched.h
> index 5a58c1270474..d26d1dfb9904 100644
> --- a/include/linux/sched.h
> +++ b/include/linux/sched.h
> @@ -1960,12 +1960,44 @@ extern void wake_up_new_task(struct task_struct *tsk);
>
> extern void kick_process(struct task_struct *tsk);
>
> +/*
> + * - Why not use task_lock()?
> + * User space can randomly change their names anyway, so locking for
> readers
> + * doesn't make sense. For writers, locking is probably necessary, as a
> race
> + * condition could lead to long-term mixed results.
> + * The logic inside __set_task_comm() should ensure that the task comm is
> + * always NUL-terminated and zero-padded. Therefore the race condition
> between
> + * reader and writer is not an issue.
> + */
> +
> extern void __set_task_comm(struct task_struct *tsk, const char *from, bool
> exec);
> #define set_task_comm(tsk, from) ({ \
> BUILD_BUG_ON(sizeof(from) < TASK_COMM_LEN); \
> __set_task_comm(tsk, from, false); \
> })
>
> +/*
> + * 'get_task_array' can be 'data-racy' in the destination and
> + * should not be used for cases where a 'stable NUL at the end'
> + * is needed. Its better to use strscpy and friends for such
> + * use-cases.
> + *
> + * It is suited mainly for a 'just copy comm to a constant-sized
> + * array' case - especially in performance sensitive use-cases,
> + * like tracing.
> + */
> +
> +static __always_inline void
> + __cstr_array_copy(char *dst, const char *src,
> + __kernel_size_t size)
> +{
> + memcpy(dst, src, size);
> + dst[size] = 0;
> +}
Please don't reinvent the wheel. :) We already have memtostr, please use
that (or memtostr_pad).
> +
> +#define get_task_array(dst, src) \
> + __cstr_array_copy(dst, src, __must_be_array(dst))
Uh, __must_be_array(dst) returns 0 on success. :P Are you sure you
tested this?
--
Kees Cook
