public inbox for linux-hardening@vger.kernel.org
 help / color / mirror / Atom feed
From: Jiri Olsa <olsajiri@gmail.com>
To: Kees Cook <kees@kernel.org>
Cc: Andrii Nakryiko <andrii@kernel.org>,
	Eduard Zingerman <eddyz87@gmail.com>,
	Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Martin KaFai Lau <martin.lau@linux.dev>,
	Song Liu <song@kernel.org>,
	Yonghong Song <yonghong.song@linux.dev>,
	John Fastabend <john.fastabend@gmail.com>,
	KP Singh <kpsingh@kernel.org>,
	Stanislav Fomichev <sdf@fomichev.me>, Hao Luo <haoluo@google.com>,
	bpf@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-hardening@vger.kernel.org
Subject: Re: [PATCH v2] libbpf: Replace strncpy() with strnlen()+memcpy() in skel_map_create()
Date: Tue, 24 Mar 2026 10:21:58 +0100	[thread overview]
Message-ID: <acJXtr10v7wE_xT9@krava> (raw)
In-Reply-To: <20260324053036.it.906-kees@kernel.org>

On Mon, Mar 23, 2026 at 10:30:37PM -0700, Kees Cook wrote:
> Replace the deprecated[1] strncpy() with strnlen() on the source
> followed by memcpy(). Normally strscpy() would be used in this case,
> but skel_internal.h is shared between kernel and userspace tools, and
> strscpy() is not available in the userspace build context.
> 
> The source map_name is a NUL-terminated C string (the only caller
> passes a 12 character string literal). The destination attr.map_name is
> char[BPF_OBJ_NAME_LEN] (16 bytes) in union bpf_attr, passed to the bpf()
> syscall. The kernel's bpf_obj_name_cpy() requires a NUL terminator within
> the 16-byte field, rejecting names that use all 16 bytes. Valid names
> are therefore at most 15 characters.
> 
> The attr is pre-zeroed with memset() at the top of the function,
> so the byte at position 15 is always NUL. The copy is bounded to
> sizeof(attr.map_name) - 1 (15 bytes) to guarantee NUL-termination is

hm, but this version no longer does that, right?

jirka


> preserved. This is safe because the kernel would reject a 16-byte
> unterminated name anyway, and the only in-tree caller passes
> "__loader.map" (12 characters).
> 
> While the original strncpy() would have copied a full 16 bytes from an
> overlong name (producing an unterminated field that the syscall rejects),
> but this shouldn't be a reachable state. Forcing truncation to 15 bytes,
> however, seemed to induce a (unrelated?) BPF selftest failure:
> https://github.com/kernel-patches/bpf/actions/runs/23472955268/job/68300440546
> 
> Allow the literal to exceed 15 characters and exactly reproduce the
> original strncpy() behavior (potentially lacking a NUL termination).
> 
> Link: https://github.com/KSPP/linux/issues/90 [1]
> Signed-off-by: Kees Cook <kees@kernel.org>
> ---
>  v2: don't force truncation
>  v1: https://lore.kernel.org/lkml/20260324040535.work.851-kees@kernel.org/
> Cc: Andrii Nakryiko <andrii@kernel.org>
> Cc: Eduard Zingerman <eddyz87@gmail.com>
> Cc: Alexei Starovoitov <ast@kernel.org>
> Cc: Daniel Borkmann <daniel@iogearbox.net>
> Cc: Martin KaFai Lau <martin.lau@linux.dev>
> Cc: Song Liu <song@kernel.org>
> Cc: Yonghong Song <yonghong.song@linux.dev>
> Cc: John Fastabend <john.fastabend@gmail.com>
> Cc: KP Singh <kpsingh@kernel.org>
> Cc: Stanislav Fomichev <sdf@fomichev.me>
> Cc: Hao Luo <haoluo@google.com>
> Cc: Jiri Olsa <jolsa@kernel.org>
> Cc: <bpf@vger.kernel.org>
> ---
>  tools/lib/bpf/skel_internal.h | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/tools/lib/bpf/skel_internal.h b/tools/lib/bpf/skel_internal.h
> index 6a8f5c7a02eb..8702d6612978 100644
> --- a/tools/lib/bpf/skel_internal.h
> +++ b/tools/lib/bpf/skel_internal.h
> @@ -243,7 +243,8 @@ static inline int skel_map_create(enum bpf_map_type map_type,
>  	attr.excl_prog_hash = (unsigned long) excl_prog_hash;
>  	attr.excl_prog_hash_size = excl_prog_hash_sz;
>  
> -	strncpy(attr.map_name, map_name, sizeof(attr.map_name));
> +	memcpy(attr.map_name, map_name,
> +	       strnlen(map_name, sizeof(attr.map_name)));
>  	attr.key_size = key_size;
>  	attr.value_size = value_size;
>  	attr.max_entries = max_entries;
> -- 
> 2.34.1
> 

  reply	other threads:[~2026-03-24  9:22 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-24  5:30 [PATCH v2] libbpf: Replace strncpy() with strnlen()+memcpy() in skel_map_create() Kees Cook
2026-03-24  9:21 ` Jiri Olsa [this message]
2026-03-24 15:26   ` Kees Cook
2026-03-24 14:50 ` Alexei Starovoitov

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=acJXtr10v7wE_xT9@krava \
    --to=olsajiri@gmail.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=eddyz87@gmail.com \
    --cc=haoluo@google.com \
    --cc=john.fastabend@gmail.com \
    --cc=kees@kernel.org \
    --cc=kpsingh@kernel.org \
    --cc=linux-hardening@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=martin.lau@linux.dev \
    --cc=sdf@fomichev.me \
    --cc=song@kernel.org \
    --cc=yonghong.song@linux.dev \
    /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