From: Ferruh Yigit <ferruh.yigit@amd.com>
To: "Etelson, Gregory" <getelson@nvidia.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>,
Maayan Kashani <mkashani@nvidia.com>,
Raslan Darawsheh <rasland@nvidia.com>, Ori Kam <orika@nvidia.com>,
Aman Singh <aman.deep.singh@intel.com>,
Yuying Zhang <yuying.zhang@intel.com>
Subject: Re: [PATCH] app/testpmd: fix indirect action list parameters parsing
Date: Fri, 10 Nov 2023 14:51:36 +0000 [thread overview]
Message-ID: <95a14c2f-f6ba-4133-b787-99c2feb8739c@amd.com> (raw)
In-Reply-To: <c1d05bd9-c97d-e229-8280-44f58baa037f@nvidia.com>
On 11/9/2023 7:57 PM, Etelson, Gregory wrote:
> Hello Ferruh,
>
>>>>> Indirect actions list arguments parser was configured to place target
>>>>> number into 64bit value, while the code provided 32bits memory.
>>>>>
>>>>
>>>> Hi Gregory,
>>>>
>>>> Can you please give more details why 'id' needs to be 64 bits, with
>>>> callstack or usecase etc?
>>>> And please describe what is the observed problem with current code?
>>>>
>>>
>>> In rte_flow.h, struct rte_flow_action_indirect_list::handle is a
>>> pointer.
>>>
>>> Testpmd ACTION_INDIRECT_LIST_HANDLE and ACTION_INDIRECT_LIST_CONF tokens
>>> define arguments size as uintptr_t.
>>>
>>> On 64 bits system, defining the id variable as 32 bits value
>>> corrupted parse_indlst_id2ptr stack.
>>>
>>
>> I can't see how stack corruption can happen, can you please provide call
>> stack and flow command?
>>
>
> To reproduce the crash buildtype must be release or debugoptimized.
> The crash will not reproduce with the debug builds.
>
> Testpmd commands I use:
>
> dpdk-testpmd -a ${PCI_ADDR},dv_flow_en=2,representor=vf0-1 -- -i
>
> port stop all
> flow configure 0 queues_number 12 queues_size 256
> flow configure 1 queues_number 12 queues_size 256
> flow configure 2 queues_number 12 queues_size 256
> port start all
> start
>
> set raw_encap 0 eth dst is 00:16:3e:52:bd:37 src is 00:16:3e:6e:16:e0
> type is 2048 has_vlan is 0 / ipv4 src is 110.240.52.255 dst is
> 189.68.183.147 proto is 17 fragment_offset is 0 packet_id is 1 tos is
> 102 ttl is 189 version_ihl is 69 / udp src is 56800 dst is 4789 / vxlan
> vni is 3 / end_set
> set sample_actions 0 represented_port ethdev_port_id 0 / end
>
> flow indirect_action 0 create action_id 5 transfer list actions sample
> ratio 1 index 0 / represented_port ethdev_port_id 2 / end
> flow actions_template 0 create transfer actions_template_id 6 template
> indirect_list handle 5 / end mask indirect_list handle 5 / end
>
> Result:
> *** stack smashing detected ***: terminated
>
> The corruption occurred in `parse_int()` called from
> `parse_indlst_id2ptr()`.
>
> Inside `parse_int()` the arg parameter referenced 8 bytes of memory
> while the target buffer was 4 bytes allocated on caller optimized stack:
>
> (gdb) p *arg
> $1 = { ... size = 8, ...}
>
Thanks Gregory, I can see the problem now.
if 'handle' is not an address, but an ID, your V3 makes sense to convert
its type to 'uint32_t', and it solves to problem. Same for 'conf'.
BUT back to the root cause of the problem,
`parse_int()` tries to be generic and it support different size of
variables [1], but it fails on this.
`parse_int()` gets 'size' as argument, but it doesn't use parameter
value, instead overwrites it with 'size = arg->size;' and uses this
value, in this case when context provides larger variable size than what
`parse_int()` gets as parameter, the problem you observed occurs.
What do you think to use 'size' from parameter list, as it is intended,
instead of using 'arg->size'?
Or perhaps use 'buf' and 'size' from parameter if they are valid, else
get the from context/arg [2]?
I think this solves your problem, can you please verify it?
btw, 'buf' usage is a little more complex, since `parse_int()` checks
for "ctx->object != NULL" to continue, I can't really be sure about
intention there, but please check usage in `parse_port()`, it looks like
when 'buf' provided expectation is to get parsed value in the 'buf'.
[1]
switch (size) {
case sizeof(uint8_t):
...
case sizeof(uint16_t):
...
...
case sizeof(uint64_t):
...
[2]
diff --git a/app/test-pmd/cmdline_flow.c b/app/test-pmd/cmdline_flow.c
index 0d521159e97d..cd123c69265e 100644
--- a/app/test-pmd/cmdline_flow.c
+++ b/app/test-pmd/cmdline_flow.c
@@ -10805,8 +10805,10 @@ parse_int(struct context *ctx, const struct
token *token,
goto error;
return len;
}
- buf = (uint8_t *)ctx->object + arg->offset;
- size = arg->size;
+ if (buf == NULL || size == 0) {
+ buf = (uint8_t *)ctx->object + arg->offset;
+ size = arg->size;
+ }
if (u > RTE_LEN2MASK(size * CHAR_BIT, uint64_t))
return -1;
objmask:
>
>>>> Inside 'parse_indlst_id2ptr()',
>>>> 'parse_int()' can work or 32bits and 64bits variables, so that one
>>>> is OK.
>>>> But both 'port_action_handle_get_by_id()' &
>>>> 'indirect_action_list_conf_get()' gets 'id' as parameter and they get
>>>> 32bits argument, when 'id' is 64bit won't it will be cast to 32bits and
>>>> loose data, should those functions needs to be updated as well.
>>>>
>>
>> Can you please reply to above question, about changing 'id' type impact
>> to other functions using it?
>>
>
> I've missed that.
> Need to re-think.
>
> Regards,
> Gregory
>
>>
>>>>
>>>>
>>>>> The patch updated variable size for translation results.
>>>>>
>>>>> Fixes: 72a3dec7126f ("ethdev: add indirect flow list action")
>>>>> Signed-off-by: Gregory Etelson <getelson@nvidia.com>
>>>>> ---
>>>>> app/test-pmd/cmdline_flow.c | 5 +++--
>>>>> 1 file changed, 3 insertions(+), 2 deletions(-)
>>>>>
>>>>> diff --git a/app/test-pmd/cmdline_flow.c b/app/test-pmd/cmdline_flow.c
>>>>> index 0d521159e9..cf1ca33208 100644
>>>>> --- a/app/test-pmd/cmdline_flow.c
>>>>> +++ b/app/test-pmd/cmdline_flow.c
>>>>> @@ -11331,7 +11331,7 @@ parse_indlst_id2ptr(struct context *ctx,
>>>>> const struct token *token,
>>>>> struct rte_flow_action *action = ctx->object;
>>>>> struct rte_flow_action_indirect_list *action_conf;
>>>>> const struct indlst_conf *indlst_conf;
>>>>> - uint32_t id;
>>>>> + uint64_t id;
>>>>> int ret;
>>>>>
>>>>> if (!action)
>>>>> @@ -11350,7 +11350,8 @@ parse_indlst_id2ptr(struct context *ctx,
>>>>> const struct token *token,
>>>>> action_conf->handle = (typeof(action_conf->handle))
>>>>> port_action_handle_get_by_id(ctx->port,
>>>>> id);
>>>>> if (!action_conf->handle) {
>>>>> - printf("no indirect list handle for id %u\n",
>>>>> id);
>>>>> + printf("no indirect list handle for id
>>>>> %"PRIu64"\n",
>>>>> + id);
>>>>> return -1;
>>>>> }
>>>>> break;
>>>>
>>>>
>>
>>
next prev parent reply other threads:[~2023-11-10 14:52 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-08 16:34 Gregory Etelson
2023-11-09 16:16 ` Ferruh Yigit
2023-11-09 18:22 ` Etelson, Gregory
2023-11-09 19:03 ` Ferruh Yigit
2023-11-09 19:57 ` Etelson, Gregory
2023-11-10 14:51 ` Ferruh Yigit [this message]
2023-11-10 17:41 ` Etelson, Gregory
2023-11-10 20:15 ` Ferruh Yigit
2023-11-10 21:22 ` Etelson, Gregory
2023-11-09 18:36 ` [PATCH v2] " Gregory Etelson
2023-11-09 19:41 ` Stephen Hemminger
2023-11-09 20:01 ` Bruce Richardson
2023-11-10 7:04 ` [PATCH v3] app/testpmd: fix indirect action list ID size Gregory Etelson
2023-11-10 23:40 ` Ferruh Yigit
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=95a14c2f-f6ba-4133-b787-99c2feb8739c@amd.com \
--to=ferruh.yigit@amd.com \
--cc=aman.deep.singh@intel.com \
--cc=dev@dpdk.org \
--cc=getelson@nvidia.com \
--cc=mkashani@nvidia.com \
--cc=orika@nvidia.com \
--cc=rasland@nvidia.com \
--cc=yuying.zhang@intel.com \
/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).