On Tue, Mar 24, 2026 at 9:23 AM Kees Cook <[email protected]> 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 <[email protected]> wrote: > > > > > > > > > > > > On March 24, 2026 7:42:04 AM PDT, Alexei Starovoitov > > > <[email protected]> wrote: > > > >On Mon, Mar 23, 2026 at 10:25 PM Kees Cook <[email protected]> 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/[email protected]/ > https://lore.kernel.org/all/[email protected]/
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.
