[dpdk-dev] [PATCH] net/i40e: fix value of num parameter for strncpy function

Rybalchenko, Kirill kirill.rybalchenko at intel.com
Mon Oct 23 15:06:05 CEST 2017



> -----Original Message-----
> From: Richardson, Bruce
> Sent: Monday 23 October 2017 13:58
> To: Rybalchenko, Kirill <kirill.rybalchenko at intel.com>
> Cc: dev at dpdk.org; Chilikin, Andrey <andrey.chilikin at intel.com>; Xing, Beilei
> <beilei.xing at intel.com>; Wu, Jingjing <jingjing.wu at intel.com>
> Subject: Re: [dpdk-dev] [PATCH] net/i40e: fix value of num parameter for
> strncpy function
> 
> On Mon, Oct 23, 2017 at 12:24:49PM +0100, Kirill Rybalchenko wrote:
> > num parameter for strncpy() function should be smaller than actual
> > destination buffer size to allow null termination.
> >
> > Fixes: 40d1324423a4 ("net/i40e: get ddp profile protocol info")
> >
> > Signed-off-by: Kirill Rybalchenko <kirill.rybalchenko at intel.com>
> > ---
> >  drivers/net/i40e/rte_pmd_i40e.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/net/i40e/rte_pmd_i40e.c
> > b/drivers/net/i40e/rte_pmd_i40e.c index 4881ea0..489f66b 100644
> > --- a/drivers/net/i40e/rte_pmd_i40e.c
> > +++ b/drivers/net/i40e/rte_pmd_i40e.c
> > @@ -1928,7 +1928,7 @@ int rte_pmd_i40e_get_ddp_info(uint8_t
> *pkg_buff, uint32_t pkg_size,
> >  		for (i = j = 0; i < nb_rec; j++) {
> >  			pinfo[j].proto_id = tlv->data[0];
> >  			strncpy(pinfo[j].name, (const char *)&tlv->data[1],
> > -				I40E_DDP_NAME_SIZE);
> > +				I40E_DDP_NAME_SIZE - 1);
> >  			i += tlv->len;
> >  			tlv = &tlv[tlv->len];
> >  		}
> > --
> 
> This is not a proper fix, as it still won't null-terminate the result.
> Replace strncpy with snprintf is probably the best solution.
The source buffer is 12 bytes long and guaranteed contains null-terminated C-string,
Destination buffer is 32 bytes long. Strncpy documentation says:
" Copies the first num characters of source to destination. If the end of the source C string (which is signaled by a null-character) is found before num characters have been copied, destination is padded with zeros until a total of num characters have been written to it."
I belive, having that, we can be sure that we'll get proper null-terminated string within destination buffer.
Or do I miss something?
> 
> /Bruce


More information about the dev mailing list