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@xxxxxxxxxx> 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@xxxxxxxxxx> wrote:
> > >
> > >
> > >
> > > On March 24, 2026 7:42:04 AM PDT, Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx> wrote:
> > > >On Mon, Mar 23, 2026 at 10:25 PM Kees Cook <kees@xxxxxxxxxx> 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@xxxxxxxxx/
> https://lore.kernel.org/all/202603241330.vmNnBWvZ-lkp@xxxxxxxxx/

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.