[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