From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id E433D1B60A for ; Mon, 23 Oct 2017 15:06:09 +0200 (CEST) Received: from orsmga003.jf.intel.com ([10.7.209.27]) by fmsmga102.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Oct 2017 06:06:08 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.43,422,1503385200"; d="scan'208";a="1028252380" Received: from irsmsx102.ger.corp.intel.com ([163.33.3.155]) by orsmga003.jf.intel.com with ESMTP; 23 Oct 2017 06:06:07 -0700 Received: from irsmsx108.ger.corp.intel.com ([169.254.11.167]) by IRSMSX102.ger.corp.intel.com ([169.254.2.180]) with mapi id 14.03.0319.002; Mon, 23 Oct 2017 14:06:07 +0100 From: "Rybalchenko, Kirill" To: "Richardson, Bruce" CC: "dev@dpdk.org" , "Chilikin, Andrey" , "Xing, Beilei" , "Wu, Jingjing" Thread-Topic: [dpdk-dev] [PATCH] net/i40e: fix value of num parameter for strncpy function Thread-Index: AQHTS/GR/PCxLRRQqUKXDAqd0sM9UaLxVGOAgAAR73A= Date: Mon, 23 Oct 2017 13:06:05 +0000 Message-ID: <696B43C21188DF4F9C9091AAE4789B824E2A50BE@IRSMSX108.ger.corp.intel.com> References: <1508757889-40845-1-git-send-email-kirill.rybalchenko@intel.com> <20171023125745.GA26976@bricha3-MOBL3.ger.corp.intel.com> In-Reply-To: <20171023125745.GA26976@bricha3-MOBL3.ger.corp.intel.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiMzFiOGIwOGYtZjQ4ZC00ZTdiLWFmNzctYjQ2NmMzNmVmMzU5IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE2LjUuOS4zIiwiVHJ1c3RlZExhYmVsSGFzaCI6IkNiWkVBQ2RFY3EybmdhRGRCSWlVdUtmcFA4SVpIR2V5M3FFWVV0aE9sdzQ9In0= x-ctpclassification: CTP_IC dlp-product: dlpe-windows dlp-version: 11.0.0.116 dlp-reaction: no-action x-originating-ip: [163.33.239.181] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH] net/i40e: fix value of num parameter for strncpy function X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Oct 2017 13:06:10 -0000 > -----Original Message----- > From: Richardson, Bruce > Sent: Monday 23 October 2017 13:58 > To: Rybalchenko, Kirill > Cc: dev@dpdk.org; Chilikin, Andrey ; Xing, Bei= lei > ; Wu, Jingjing > Subject: Re: [dpdk-dev] [PATCH] net/i40e: fix value of num parameter for > strncpy function >=20 > 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 > > --- > > 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 =3D j =3D 0; i < nb_rec; j++) { > > pinfo[j].proto_id =3D tlv->data[0]; > > strncpy(pinfo[j].name, (const char *)&tlv->data[1], > > - I40E_DDP_NAME_SIZE); > > + I40E_DDP_NAME_SIZE - 1); > > i +=3D tlv->len; > > tlv =3D &tlv[tlv->len]; > > } > > -- >=20 > 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 t= he 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 t= otal 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? >=20 > /Bruce