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.
-Kees
--
Kees Cook
