> diff --git a/kernel/bpf/helpers.c b/kernel/bpf/helpers.c
> index c18f1e16edee..85afff60365c 100644
> --- a/kernel/bpf/helpers.c
> +++ b/kernel/bpf/helpers.c
> @@ -4195,6 +4195,79 @@ __bpf_kfunc int bpf_strncasestr(const char *s1__ign,
> const char *s2__ign,
> return __bpf_strnstr(s1__ign, s2__ign, len, true);
> }
>
> +static int __bpf_strncat(char *dst, u32 dsz, const char *src, u32 sz)
> +{
> + int dlen = 0, slen, space, copied;
> +
> + if (sz == 0 || dsz == 0)
> + return -EINVAL;
> +
> + while (dlen < dsz && dst[dlen] != '\0')
> + dlen++;
> +
> + if (dlen >= dsz)
> + return -E2BIG;
> +
> + space = dsz - dlen;
> +
> + slen = bpf_strnlen(src, sz);
This came up in the earlier review of the series: the length of src does not
need to be computed here, since strncpy_from_kernel_nofault() already bounds
the copy by sz.
https://lore.kernel.org/bpf/[email protected]/
That bpf_strnlen(src, sz) call was dropped in an earlier revision and has
returned in this one. Is the separate src length scan still needed here, or
can strncpy_from_kernel_nofault() handle the bound on its own?
> + if (space <= slen)
> + return -E2BIG;
> +
> + copied = strncpy_from_kernel_nofault(dst + dlen, src, sz);
> + if (copied < 0)
> + return copied;
> + else if (copied == 0 || copied == 1)
> + return dlen;
> +
> + /* The copied character count includes '\0'. */
> + return dlen + copied - 1;
> +}
[ ... ]
---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md
CI run summary: https://github.com/kernel-patches/bpf/actions/runs/29894636510
