From: Aaron Conole <aconole@redhat.com>
To: Ferruh Yigit <ferruh.yigit@intel.com>
Cc: "Parthasarathy\, JananeeX M" <jananeex.m.parthasarathy@intel.com>,
"'dev\@dpdk.org'" <dev@dpdk.org>, "Pattan\,
Reshma" <reshma.pattan@intel.com>, "Rao\,
Nikhil" <nikhil.rao@intel.com>,
"'stable\@dpdk.org'" <stable@dpdk.org>, "Poornima\,
PallantlaX" <pallantlax.poornima@intel.com>
Subject: Re: [dpdk-dev] [dpdk-stable] [PATCH] test/eventdev: fix sprintf with snprintf
Date: Wed, 13 Mar 2019 09:43:01 -0400 [thread overview]
Message-ID: <f7ta7hyriu2.fsf@dhcp-25.97.bos.redhat.com> (raw)
In-Reply-To: <fa21b43f-2788-1085-e6df-b49f3c6a5c71@intel.com> (Ferruh Yigit's message of "Wed, 13 Mar 2019 11:04:59 +0000")
Ferruh Yigit <ferruh.yigit@intel.com> writes:
> On 3/12/2019 2:44 PM, Aaron Conole wrote:
>> "Parthasarathy, JananeeX M" <jananeex.m.parthasarathy@intel.com> writes:
>>
>>> Hi
>>>
>>>> -----Original Message-----
>>>> From: Parthasarathy, JananeeX M
>>>> Sent: Tuesday, February 19, 2019 6:33 PM
>>>> To: Aaron Conole <aconole@redhat.com>; Poornima, PallantlaX
>>>> <pallantlax.poornima@intel.com>
>>>> Cc: dev@dpdk.org; Pattan, Reshma <reshma.pattan@intel.com>; Rao, Nikhil
>>>> <nikhil.rao@intel.com>; stable@dpdk.org
>>>> Subject: RE: [dpdk-dev] [PATCH] test/eventdev: fix sprintf with snprintf
>>>>
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Aaron Conole
>>>>> Sent: Saturday, February 09, 2019 2:50 AM
>>>>> To: Poornima, PallantlaX <pallantlax.poornima@intel.com>
>>>>> Cc: dev@dpdk.org; Pattan, Reshma <reshma.pattan@intel.com>; Rao, Nikhil
>>>>> <nikhil.rao@intel.com>; stable@dpdk.org
>>>>> Subject: Re: [dpdk-dev] [PATCH] test/eventdev: fix sprintf with
>>>>> snprintf
>>>>>
>>>>> Pallantla Poornima <pallantlax.poornima@intel.com> writes:
>>>>>
>>>>>> sprintf function is not secure as it doesn't check the length of string.
>>>>>> More secure function snprintf is used.
>>>>>>
>>>>>> Fixes: 2a9c83ae3b ("test/eventdev: add multi-ports test")
>>>>>> Cc: stable@dpdk.org
>>>>>>
>>>>>> Signed-off-by: Pallantla Poornima <pallantlax.poornima@intel.com>
>>>>>> ---
>>>>>> test/test/test_event_eth_rx_adapter.c | 3 ++-
>>>>>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>>>>>
>>>>>> diff --git a/test/test/test_event_eth_rx_adapter.c
>>>>>> b/test/test/test_event_eth_rx_adapter.c
>>>>>> index 1d3be82b5..38f5c039f 100644
>>>>>> --- a/test/test/test_event_eth_rx_adapter.c
>>>>>> +++ b/test/test/test_event_eth_rx_adapter.c
>>>>>> @@ -479,7 +479,8 @@ adapter_multi_eth_add_del(void)
>>>>>> /* add the max port for rx_adapter */
>>>>>> port_index = rte_eth_dev_count_total();
>>>>>> for (; port_index < RTE_MAX_ETHPORTS; port_index += 1) {
>>>>>> - sprintf(driver_name, "%s%u", "net_null", drv_id);
>>>>>> + snprintf(driver_name, sizeof(driver_name), "%s%u", "net_null",
>>>>>> + drv_id);
>>>>>> err = rte_vdev_init(driver_name, NULL);
>>>>>> TEST_ASSERT(err == 0, "Failed driver %s got %d",
>>>>>> driver_name, err);
>>>>>
>>>>> You call this a fix, but it's not possible for the value of drv_id to
>>>>> exceed '32' and the buffer size is plenty accommodating for that. Did
>>>>> I miss something? What is this fixing?
>>>>
>>>> It is better practice to use snprintf although in this case buffer will not overflow
>>>> as size is big enough to accommodate. The changes were done mainly to
>>>> replace sprintf to snprintf. Probably we can remove "fix" line as it is not issue in
>>>> this scenario.
>>>>
>>>> Thanks
>>>> M.P.Jananee
>>>
>>> Please suggest if we can remove "fix" line.
>>
>> This is a stylistic change, I don't think it's appropriate to call it a
>> fix, so I think you can remove the "Fixes" line.
>>
>> On further reflection, I actually think it will still be wrong. If the
>> size buffer is ever changed, what will happen on truncation? We don't
>> get an overflow any longer, but we still pass an invalid argument, so I
>> don't think this 'fix' is really even a fix. It still has a bug -
>> albeit not one that immediately triggers SSP exception or stack
>> overflow.
>>
>> Makes sense?
>
> Hi Aaron,
>
> I see your point and I agree that existing code is not broken, it is functioning
> well as it is.
>
> But we are fixing a possible issue, or lets say fixing using less secure API
> although it doesn't cause any problem right now. Perhaps we can update the patch
> title slightly [1] but I am for keeping the fix and I think it makes sense to
> keep "Fixes" tag so that this update can be backported to stable trees.
I can get behind changing the sprintf to snprintf, since it is a better
API - but it needs to handle the return value properly (otherwise, in
this case we will specify an incorrect device). I can even
understanding calling it a fix, it's metadata and is probably needed
from some kind of compliance anyway.
I also understand that this is in test suite, but people usually copy
code from test suites and that means the flaw at some point will be
propagated. So I still think it should be a version which checks the
return code. Otherwise in production if this is copied, and if I can
figure out how to overflow the counter knowing the buffer boundaries,
then there is a fixed device that will always be chosen.
I think it goes for all the other 's/sprintf\(/snprintf\)' replacements,
too. Maybe I misunderstand something?
> Thanks,
> ferruh
>
> [1]
> test/eventdev: fix possible buffer overflow
next prev parent reply other threads:[~2019-03-13 13:43 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-06 10:43 [dpdk-dev] " Pallantla Poornima
2019-02-08 21:19 ` Aaron Conole
[not found] ` <7AE31235A30B41498D1C31348DC858BD5B534A73@IRSMSX103.ger.corp.intel.com>
2019-03-12 7:41 ` Parthasarathy, JananeeX M
2019-03-12 14:44 ` Aaron Conole
2019-03-13 11:04 ` [dpdk-dev] [dpdk-stable] " Ferruh Yigit
2019-03-13 13:43 ` Aaron Conole [this message]
2019-03-13 14:07 ` Ferruh Yigit
2019-03-13 14:35 ` Aaron Conole
2019-03-30 14:15 ` Jerin Jacob Kollanukkaran
2019-03-30 14:15 ` Jerin Jacob Kollanukkaran
2019-04-01 20:37 ` Aaron Conole
2019-04-01 20:37 ` Aaron Conole
2019-04-02 1:35 ` [dpdk-dev] [EXT] " Jerin Jacob Kollanukkaran
2019-04-02 1:35 ` Jerin Jacob Kollanukkaran
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=f7ta7hyriu2.fsf@dhcp-25.97.bos.redhat.com \
--to=aconole@redhat.com \
--cc=dev@dpdk.org \
--cc=ferruh.yigit@intel.com \
--cc=jananeex.m.parthasarathy@intel.com \
--cc=nikhil.rao@intel.com \
--cc=pallantlax.poornima@intel.com \
--cc=reshma.pattan@intel.com \
--cc=stable@dpdk.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).