[dpdk-stable] [PATH 17.11] net/nfp: fix misuse of strlcpy
Yongseok Koh
yskoh at mellanox.com
Sat Feb 16 08:49:13 CET 2019
> On Feb 15, 2019, at 7:30 PM, Alejandro Lucero <alejandro.lucero at netronome.com> wrote:
>
> Current strlcpy function is doing the wrong thing and as a consequence
> the firmware does not find the symbol requested precluding the right
> NFP initialization.
Applied to stable/17.11.
However, can you explain what strlcpy does wrong?
If it is buggy, we should fix it as there are quite a few occurrences,
due to the new gcc.
Thanks,
Yongseok
> Using strncpy is safe here since the symbol length can never be longer
> than the buffer size where the firmware will get the symbol to work
> with. However, newer compilers do not allow to have the strncpy using
> the source length as the third parameter, so this patch uses instead a
> memcpy call with a previous memset for cleaning up the buffer to be
> used by the firmware.
>
> Fixes: a5d659c2d03f ("net/nfp: replace strncpy by strlcpy")
>
> Signed-off-by: Alejandro Lucero <alejandro.lucero at netronome.com>
> ---
> drivers/net/nfp/nfp_nspu.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/nfp/nfp_nspu.c b/drivers/net/nfp/nfp_nspu.c
> index ac5bce3b1..d4abb6c8e 100644
> --- a/drivers/net/nfp/nfp_nspu.c
> +++ b/drivers/net/nfp/nfp_nspu.c
> @@ -424,7 +424,9 @@ nfp_nspu_set_bar_from_symbl(nspu_desc_t *desc, const char *symbl,
> if (!sym_buf)
> return -ENOMEM;
>
> - strlcpy(sym_buf, symbl, sizeof(sym_buf));
> + memset(sym_buf, 0, desc->buf_size);
> + memcpy(sym_buf, symbl, strlen(symbl));
> +
> ret = nspu_command(desc, NSP_CMD_GET_SYMBOL, 1, 1, sym_buf,
> NFP_SYM_DESC_LEN, strlen(symbl));
> if (ret) {
> --
> 2.17.1
>
More information about the stable
mailing list