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]/

(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

Reply via email to