[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20240330201036.GA22418@kernel.org>
Date: Sat, 30 Mar 2024 20:10:36 +0000
From: Simon Horman <horms@...nel.org>
To: Jakub Kicinski <kuba@...nel.org>
Cc: Aleksandr Mishin <amishin@...rgos.ru>,
Sunil Goutham <sgoutham@...vell.com>,
Linu Cherian <lcherian@...vell.com>,
Geetha sowjanya <gakula@...vell.com>,
Jerin Jacob <jerinj@...vell.com>, hariprasad <hkelam@...vell.com>,
Subbaraya Sundeep <sbhatta@...vell.com>,
"David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>, Paolo Abeni <pabeni@...hat.com>,
netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
lvc-project@...uxtesting.org
Subject: Re: [PATCH] octeontx2-af: Add array index check
On Thu, Mar 28, 2024 at 11:28:18AM -0700, Jakub Kicinski wrote:
> On Thu, 28 Mar 2024 11:16:48 +0300 Aleksandr Mishin wrote:
> > In rvu_map_cgx_lmac_pf() the 'iter', which is used as an array index, can reach
> > value (up to 14) that exceed the size (MAX_LMAC_COUNT = 8) of the array.
> > Fix this bug by adding 'iter' value check.
>
> I'm guessing you got the 14 from:
>
> hw->lmac_per_cgx = (nix_const >> 8) & 0xFULL;
>
> Seems more reasonable to cap the size at that point than every use
> afterwards.
FWIIW, I didn't find any other locations where this overflow might occur,
but I do agree that this approach makes sense.
I also notice that rvu_map_cgx_lmac_pf() has the following check near the
top. I think the lmac_per_cgx portion can be dropped, though that could be
a follow-up.
if (cgx_cnt_max > 0xF || rvu->hw->lmac_per_cgx > 0xF)
return -EINVAL;
Powered by blists - more mailing lists