lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:	Tue, 2 Aug 2016 17:02:54 +0530
From:	Sunil Kovvuri <sunil.kovvuri@...il.com>
To:	"Levin, Alexander" <alexander.levin@...izon.com>
Cc:	"sgoutham@...ium.com" <sgoutham@...ium.com>,
	"rric@...nel.org" <rric@...nel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] net: thunderx: correct bound check in nic_config_loopback

Yes, it's incorrect at other places as well.
That went in the very early stages of development and didn't change it because
that out of bounds issue will never happen as no of logical interfaces
will never be
morethan  MAX_LMAC i.e 8, so max vf_id will be 7.

But with addition of support for newer platforms with different set HW
capabilities we
are slowly getting rid of most of the macros i.e static info.
Attached is the patch which will get rid of MAX_LMAC and also allows
support for 16LMACs (supported on newer platforms) or more.

I hope currently you are not facing any issue with below check.
>>> if (lbk->vf_id > MAX_LMAC)

I will submit the attached patch along with other patches when net-next is open.
https://lkml.org/lkml/2016/7/15/362

Thanks,
Sunil.

On Mon, Aug 1, 2016 at 9:27 PM, Levin, Alexander
<alexander.levin@...izon.com> wrote:
> On 07/31/2016 12:41 PM, Sunil Kovvuri wrote:
>> Thanks for finding.
>> A much better fix would be,
>>
>> -       if (lbk->vf_id > MAX_LMAC)
>> +       if (lbk->vf_id >= nic->num_vf_en)
>>                 return -1;
>>
>> where 'num_vf_en' reflects the exact number of physical interfaces or
>> LMACs on the system.
>
> Right. I see quite a few more places that compare to MAX_LMAC vs
> num_vf_en. What was the reasoning behind it then?
>
>
> Thanks,
> Sasha

View attachment "0001-net-thunderx-Add-support-for-16-LMACs-of-83xx.patch" of type "text/x-patch" (5390 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ