> -----邮件原件----- > 发件人: Olivier Matz [mailto:olivier.m...@6wind.com] > 发送时间: 2020年3月26日 0:32 > 收件人: wangyunjian <wangyunj...@huawei.com> > 抄送: dev@dpdk.org; Lilijun (Jerry) <jerry.lili...@huawei.com>; xudingke > <xudin...@huawei.com>; sta...@dpdk.org > 主题: Re: [dpdk-dev] [PATCH] kvargs: fix a heap-buffer-overflow when detect > list > > Hi, > > On Thu, Mar 19, 2020 at 12:38:00PM +0800, wangyunjian wrote: > > From: Yunjian Wang <wangyunj...@huawei.com> > > > > When an input params'value is '[', leading to the 'str' over read or > > heap-buffer-overflow. So we can check the 'ctx1' length to avoid this > > problem. > > > > Fixes: cc0579f2339a ("kvargs: support list value") > > Cc: sta...@dpdk.org > > > > Signed-off-by: Yunjian Wang <wangyunj...@huawei.com> > > --- > > lib/librte_kvargs/rte_kvargs.c | 3 ++- > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > diff --git a/lib/librte_kvargs/rte_kvargs.c > > b/lib/librte_kvargs/rte_kvargs.c index d39332999..a1144b90b 100644 > > --- a/lib/librte_kvargs/rte_kvargs.c > > +++ b/lib/librte_kvargs/rte_kvargs.c > > @@ -48,7 +48,8 @@ rte_kvargs_tokenize(struct rte_kvargs *kvlist, const > char *params) > > str = kvlist->pairs[i].value; > > if (str[0] == '[') { > > /* Find the end of the list. */ > > - while (str[strlen(str) - 1] != ']') { > > + while ((str[strlen(str) - 1] != ']') && > > + (strlen(ctx1) > 0)) { > > /* Restore the comma erased by strtok_r(). */ > > str[strlen(str)] = ','; > > /* Parse until next comma. */ > > I would prefer to keep the while condition as is, like this: > > /* Restore the comma erased by > strtok_r(). */ > + if (ctx1[0] == '\0') > + return -1; /* no closing > bracket > + */ > str[strlen(str)] = ','; > > It avoids an uneeded call to strlen(), and ensure we are returning an error in > that case. > > I also wanted to add a test case, but I realized that kvargs unit tests are > broken > now. I have done 2 patches to fix them. > > Do you mind if I send a patchset with these 2 patches + your patch (keeping > your signed-off and doing the modification described above), to ensure there > is > no implicit dependency?
No, I don’t mind. I agree with your view. Thanks Yunjian > > Thanks, > Olivier
