Re: [PATCH v2] RDMA/hns: Fix arithmetic overflow in hns_roce_v2_set_hem()

[David Laight <david.laight.linux@gmail.com>]

On Thu, 9 Jul 2026 04:56:56 +0000
Alexander Chesnokov <Alexander.Chesnokov@kaspersky.com> wrote:

> > When does the value overflow.
> > Yes, the expression can overflow and the result is assigned to a
> > 64bit variable, but I'd have testing this code would have showed
> > the problem. So what is the customer visible impact?  
> 
> You're right, there is no reachable overflow. In hns_roce_calc_hem_mhop()
> the 32-bit table_idx is split into base-chunk_ba_num digits i, j, k, and
> here they are recombined: i * chunk_ba_num + j equals table_idx /
> chunk_ba_num, and the full expression equals table_idx, which is u32.
> i is additionally bounded by ba_l0_num. So the arithmetic cannot exceed
> U32_MAX on any real input - there is no customer-visible impact, and the
> SVACE report is a false positive.
> 
> I'll drop the Fixes: and Cc: stable tags and resend as a standalone
> hardening/readability change. If you'd prefer to just drop it, that's
> fine too.

Best just dropped.

	David

> 
> -----Original Message-----
> From: David Laight <david.laight.linux@gmail.com> 
> Sent: Wednesday, July 8, 2026 8:20 PM
> To: Alexander Chesnokov <Alexander.Chesnokov@kaspersky.com>
> Cc: xuhaoyue1@hisilicon.com; lvc-project@linuxtesting.org; Oleg Kazakov <Oleg.Kazakov@kaspersky.com>; Pavel Zhigulin <Pavel.Zhigulin@kaspersky.com>; stable@vger.kernel.org; Wenpeng Liang <liangwenpeng@huawei.com>; Jason Gunthorpe <jgg@ziepe.ca>; Leon Romanovsky <leon@kernel.org>; Xi Wang <wangxi11@huawei.com>; Weihang Li <liweihang@huawei.com>; linux-rdma@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH v2] RDMA/hns: Fix arithmetic overflow in hns_roce_v2_set_hem()
> 
> Caution: This is an external email.
> 
> 
> 
> On Wed, 8 Jul 2026 12:21:46 +0300
> <Alexander.Chesnokov@kaspersky.com> wrote:
> 
> > From: Alexander Chesnokov <Alexander.Chesnokov@kaspersky.com>
> >
> > If hop_num is 2 or 1, then the expressions like i * chunk_ba_num + j 
> > are computed in 32-bit arithmetic before being assigned to a u64 index 
> > field, which can lead to overflow.  
> 
> When does the value overflow.
> Yes, the expression can overflow and the result is assigned to a 64bit variable, but I'd have testing this code would have showed the problem.
> 
> So what is the customer visible impact?
> 
>         David
> 
> >
> > Declare i, j and k as u64 so that the address index arithmetic is 
> > performed in 64-bit.
> >
> > Found by Linux Verification Center (linuxtesting.org) with SVACE.
> >
> > Fixes: a81fba28136d ("RDMA/hns: Configure BT BA and BT attribute for 
> > the contexts in hip08")
> > Cc: stable@vger.kernel.org
> > Suggested-by: David Laight <david.laight.linux@gmail.com>
> > Signed-off-by: Alexander Chesnokov <Alexander.Chesnokov@kaspersky.com>
> >
> > ---
> > Changes in v2:
> > - Instead of casting the operands to u64, declare i, j and k as u64
> >   so the index arithmetic is performed in 64-bit (David Laight).
> >
> > v1: 
> > https://lore.kernel.org/linux-rdma/20260707140938.3106919-1-Alexander.
> > Chesnokov@kaspersky.com/
> > ---
> >  drivers/infiniband/hw/hns/hns_roce_hw_v2.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/infiniband/hw/hns/hns_roce_hw_v2.c 
> > b/drivers/infiniband/hw/hns/hns_roce_hw_v2.c
> > index 1c180a6b1c07..3469a9a68d3b 100644
> > --- a/drivers/infiniband/hw/hns/hns_roce_hw_v2.c
> > +++ b/drivers/infiniband/hw/hns/hns_roce_hw_v2.c
> > @@ -4238,7 +4238,7 @@ static int hns_roce_v2_set_hem(struct hns_roce_dev *hr_dev,
> >       struct hns_roce_hem_mhop mhop;
> >       struct hns_roce_hem *hem;
> >       unsigned long mhop_obj = obj;
> > -     int i, j, k;
> > +     u64 i, j, k;
> >       int ret = 0;
> >       u64 hem_idx = 0;
> >       u64 l1_idx = 0;  
>