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.
