[PATCH] libbpf: Replace strncpy() with strnlen()+memcpy() in skel_map_create()

[PATCH] libbpf: Replace strncpy() with strnlen()+memcpy() in skel_map_create()

[Kees Cook]

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 wasn't a reachable state. This replacement will instead always
truncate to 15 bytes and keeps the NUL terminator, which should have no
behavioral changes with the present code and avoids potential issues
with future over-long string literals.

Link: https://github.com/KSPP/linux/issues/90 [1]
Signed-off-by: Kees Cook <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..137da935f478 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) - 1));
 	attr.key_size = key_size;
 	attr.value_size = value_size;
 	attr.max_entries = max_entries;
-- 
2.34.1

Re: [PATCH] libbpf: Replace strncpy() with strnlen()+memcpy() in skel_map_create()

[Kees Cook]

On Mon, Mar 23, 2026 at 09:05:39PM -0700, Kees Cook wrote:
> 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 wasn't a reachable state. This replacement will instead always
> truncate to 15 bytes and keeps the NUL terminator, which should have no
> behavioral changes with the present code and avoids potential issues
> with future over-long string literals.

Hm, I got a failure report, but it *seems* unrelated? But nothing else
fails that way recently, so I will try a v2 with the "unterminated at 16
bytes" behavior restored and see if it passes...

test_progs_no_alu32-x86_64-llvm-21:
https://github.com/kernel-patches/bpf/actions/runs/23472955268/job/68300440546


-- 
Kees Cook

Re: [PATCH] libbpf: Replace strncpy() with strnlen()+memcpy() in skel_map_create()

[sun jian]

On Tue, Mar 24, 2026 at 1:26 PM Kees Cook <kees@kernel.org> wrote:
>
> On Mon, Mar 23, 2026 at 09:05:39PM -0700, Kees Cook wrote:
> > 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 wasn't a reachable state. This replacement will instead always
> > truncate to 15 bytes and keeps the NUL terminator, which should have no
> > behavioral changes with the present code and avoids potential issues
> > with future over-long string literals.
>
> Hm, I got a failure report, but it *seems* unrelated? But nothing else
> fails that way recently, so I will try a v2 with the "unterminated at 16
> bytes" behavior restored and see if it passes...
>
> test_progs_no_alu32-x86_64-llvm-21:
> https://github.com/kernel-patches/bpf/actions/runs/23472955268/job/68300440546
IMHO, it's a flaky test failure, likely caused by timer-related
activity when selftests/bpf
are running concurrently.

As for your patch, replacing strncpy() makes sense, but this also
changes semantics
for overlong map names: they are silently truncated to 15 bytes.
I'd prefer an explicit length check and rejecting the overlong names,
instead of normalizing
them by truncation.

Sun Jian

Re: [PATCH] libbpf: Replace strncpy() with strnlen()+memcpy() in skel_map_create()

[Alexei Starovoitov]

On Mon, Mar 23, 2026 at 10:25 PM Kees Cook <kees@kernel.org> wrote:
>
> On Mon, Mar 23, 2026 at 09:05:39PM -0700, Kees Cook wrote:
> > 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 wasn't a reachable state. This replacement will instead always
> > truncate to 15 bytes and keeps the NUL terminator, which should have no
> > behavioral changes with the present code and avoids potential issues
> > with future over-long string literals.
>
> Hm, I got a failure report, but it *seems* unrelated? But nothing else
> fails that way recently, so I will try a v2 with the "unterminated at 16
> bytes" behavior restored and see if it passes...
>
> test_progs_no_alu32-x86_64-llvm-21:
> https://github.com/kernel-patches/bpf/actions/runs/23472955268/job/68300440546

Don't fix what is not broken.

pw-bot: cr

Re: [PATCH] libbpf: Replace strncpy() with strnlen()+memcpy() in skel_map_create()

[Kees Cook]

On March 24, 2026 7:42:04 AM PDT, Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote:
>On Mon, Mar 23, 2026 at 10:25 PM Kees Cook <kees@kernel.org> wrote:
>>
>> On Mon, Mar 23, 2026 at 09:05:39PM -0700, Kees Cook wrote:
>> > 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 wasn't a reachable state. This replacement will instead always
>> > truncate to 15 bytes and keeps the NUL terminator, which should have no
>> > behavioral changes with the present code and avoids potential issues
>> > with future over-long string literals.
>>
>> Hm, I got a failure report, but it *seems* unrelated? But nothing else
>> fails that way recently, so I will try a v2 with the "unterminated at 16
>> bytes" behavior restored and see if it passes...
>>
>> test_progs_no_alu32-x86_64-llvm-21:
>> https://github.com/kernel-patches/bpf/actions/runs/23472955268/job/68300440546
>
>Don't fix what is not broken.

strncpy is broken. ;) This is one of the 6 remaining uses of strncpy in the kernel. But it needs a v3. I'll add explicit rejection of over-long strings and validate that the bpf test was a flake, as suggested in the other reply.

-Kees

-- 
Kees Cook

Re: [PATCH] libbpf: Replace strncpy() with strnlen()+memcpy() in skel_map_create()

[Alexei Starovoitov]

On Tue, Mar 24, 2026 at 8:28 AM Kees Cook <kees@kernel.org> wrote:
>
>
>
> On March 24, 2026 7:42:04 AM PDT, Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote:
> >On Mon, Mar 23, 2026 at 10:25 PM Kees Cook <kees@kernel.org> wrote:
> >>
> >> On Mon, Mar 23, 2026 at 09:05:39PM -0700, Kees Cook wrote:
> >> > 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 wasn't a reachable state. This replacement will instead always
> >> > truncate to 15 bytes and keeps the NUL terminator, which should have no
> >> > behavioral changes with the present code and avoids potential issues
> >> > with future over-long string literals.
> >>
> >> Hm, I got a failure report, but it *seems* unrelated? But nothing else
> >> fails that way recently, so I will try a v2 with the "unterminated at 16
> >> bytes" behavior restored and see if it passes...
> >>
> >> test_progs_no_alu32-x86_64-llvm-21:
> >> https://github.com/kernel-patches/bpf/actions/runs/23472955268/job/68300440546
> >
> >Don't fix what is not broken.
>
> strncpy is broken. ;) This is one of the 6 remaining uses of strncpy in the kernel. But it needs a v3. I'll add explicit rejection of over-long strings and validate that the bpf test was a flake, as suggested in the other reply.

Don't. it's not a kernel.

Re: [PATCH] libbpf: Replace strncpy() with strnlen()+memcpy() in skel_map_create()

[Kees Cook]

On Tue, Mar 24, 2026 at 08:38:48AM -0700, Alexei Starovoitov wrote:
> On Tue, Mar 24, 2026 at 8:28 AM Kees Cook <kees@kernel.org> wrote:
> >
> >
> >
> > On March 24, 2026 7:42:04 AM PDT, Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote:
> > >On Mon, Mar 23, 2026 at 10:25 PM Kees Cook <kees@kernel.org> wrote:
> > >>
> > >> On Mon, Mar 23, 2026 at 09:05:39PM -0700, Kees Cook wrote:
> > >> > 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 wasn't a reachable state. This replacement will instead always
> > >> > truncate to 15 bytes and keeps the NUL terminator, which should have no
> > >> > behavioral changes with the present code and avoids potential issues
> > >> > with future over-long string literals.
> > >>
> > >> Hm, I got a failure report, but it *seems* unrelated? But nothing else
> > >> fails that way recently, so I will try a v2 with the "unterminated at 16
> > >> bytes" behavior restored and see if it passes...
> > >>
> > >> test_progs_no_alu32-x86_64-llvm-21:
> > >> https://github.com/kernel-patches/bpf/actions/runs/23472955268/job/68300440546
> > >
> > >Don't fix what is not broken.
> >
> > strncpy is broken. ;) This is one of the 6 remaining uses of strncpy in the kernel. But it needs a v3. I'll add explicit rejection of over-long strings and validate that the bpf test was a flake, as suggested in the other reply.
> 
> Don't. it's not a kernel.

This is a very terse reply, so I'm not sure what you're trying to tell
me.

Do you mean to say that this header is not used by the Linux kernel
build? If so, that's a misunderstanding. I found this case due to 0day
complaining about it after I removed the kernel's strncpy implementations:
https://lore.kernel.org/all/202603240325.rd8gRV6s-lkp@intel.com/
https://lore.kernel.org/all/202603241330.vmNnBWvZ-lkp@intel.com/

(I had originally ignored tools/ since normally the files there are not
included in kernel builds, but this didn't seem to be the case for this
BPF header.)

-Kees

-- 
Kees Cook

Re: [PATCH] libbpf: Replace strncpy() with strnlen()+memcpy() in skel_map_create()

[Alexei Starovoitov]

On Tue, Mar 24, 2026 at 9:23 AM Kees Cook <kees@kernel.org> wrote:
>
> On Tue, Mar 24, 2026 at 08:38:48AM -0700, Alexei Starovoitov wrote:
> > On Tue, Mar 24, 2026 at 8:28 AM Kees Cook <kees@kernel.org> wrote:
> > >
> > >
> > >
> > > On March 24, 2026 7:42:04 AM PDT, Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote:
> > > >On Mon, Mar 23, 2026 at 10:25 PM Kees Cook <kees@kernel.org> wrote:
> > > >>
> > > >> On Mon, Mar 23, 2026 at 09:05:39PM -0700, Kees Cook wrote:
> > > >> > 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 wasn't a reachable state. This replacement will instead always
> > > >> > truncate to 15 bytes and keeps the NUL terminator, which should have no
> > > >> > behavioral changes with the present code and avoids potential issues
> > > >> > with future over-long string literals.
> > > >>
> > > >> Hm, I got a failure report, but it *seems* unrelated? But nothing else
> > > >> fails that way recently, so I will try a v2 with the "unterminated at 16
> > > >> bytes" behavior restored and see if it passes...
> > > >>
> > > >> test_progs_no_alu32-x86_64-llvm-21:
> > > >> https://github.com/kernel-patches/bpf/actions/runs/23472955268/job/68300440546
> > > >
> > > >Don't fix what is not broken.
> > >
> > > strncpy is broken. ;) This is one of the 6 remaining uses of strncpy in the kernel. But it needs a v3. I'll add explicit rejection of over-long strings and validate that the bpf test was a flake, as suggested in the other reply.
> >
> > Don't. it's not a kernel.
>
> This is a very terse reply, so I'm not sure what you're trying to tell
> me.
>
> Do you mean to say that this header is not used by the Linux kernel
> build? If so, that's a misunderstanding. I found this case due to 0day
> complaining about it after I removed the kernel's strncpy implementations:
> https://lore.kernel.org/all/202603240325.rd8gRV6s-lkp@intel.com/
> https://lore.kernel.org/all/202603241330.vmNnBWvZ-lkp@intel.com/

skel_internal.h is dual purpose.
In that case it's used by "kernel light skeleton".
but mainly used by "user space light skeleton".
I guess it's a grey line whether it can be considered kernel or not.

> (I had originally ignored tools/ since normally the files there are not
> included in kernel builds, but this didn't seem to be the case for this
> BPF header.)

And please keep ignoring it.
It's not broken. Don't fix it.

Re: [PATCH] libbpf: Replace strncpy() with strnlen()+memcpy() in skel_map_create()

[Kees Cook]

On Tue, Mar 24, 2026 at 09:31:09AM -0700, Alexei Starovoitov wrote:
> And please keep ignoring it.
> It's not broken. Don't fix it.

Okay. I'm confused, though: what's your plan for when strncpy is removed
from the kernel?

-- 
Kees Cook

Re: [PATCH] libbpf: Replace strncpy() with strnlen()+memcpy() in skel_map_create()

[Alexei Starovoitov]

On Tue, Mar 24, 2026 at 9:10 PM Kees Cook <kees@kernel.org> wrote:
>
> On Tue, Mar 24, 2026 at 09:31:09AM -0700, Alexei Starovoitov wrote:
> > And please keep ignoring it.
> > It's not broken. Don't fix it.
>
> Okay. I'm confused, though: what's your plan for when strncpy is removed
> from the kernel?

when it gets to the point to be actually removed then we will deal with it.
Until then it's a witch-hunt.
memcpy(,, strnlen()) is no better than strncpy.