public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Kees Cook <kees@kernel.org>
To: Andrii Nakryiko <andrii@kernel.org>
Cc: Kees Cook <kees@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>,
	Jiri Olsa <jolsa@kernel.org>,
	bpf@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-hardening@vger.kernel.org
Subject: [PATCH v2] libbpf: Replace strncpy() with strnlen()+memcpy() in skel_map_create()
Date: Mon, 23 Mar 2026 22:30:37 -0700	[thread overview]
Message-ID: <20260324053036.it.906-kees@kernel.org> (raw)

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
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  5:30 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-24  5:30 Kees Cook [this message]
2026-03-24  9:21 ` [PATCH v2] libbpf: Replace strncpy() with strnlen()+memcpy() in skel_map_create() Jiri Olsa
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=20260324053036.it.906-kees@kernel.org \
    --to=kees@kernel.org \
    --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=jolsa@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