[lvc-project] [PATCH v2] RDMA/hns: Fix arithmetic overflow in hns_roce_v2_set_hem()

[Alexander Chesnokov]

> 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.

-----Original Message-----
From: David Laight <david.laight.linux at gmail.com> 
Sent: Wednesday, July 8, 2026 8:20 PM
To: Alexander Chesnokov <Alexander.Chesnokov at kaspersky.com>
Cc: xuhaoyue1 at hisilicon.com; lvc-project at linuxtesting.org; Oleg Kazakov <Oleg.Kazakov at kaspersky.com>; Pavel Zhigulin <Pavel.Zhigulin at kaspersky.com>; stable at vger.kernel.org; Wenpeng Liang <liangwenpeng at huawei.com>; Jason Gunthorpe <jgg at ziepe.ca>; Leon Romanovsky <leon at kernel.org>; Xi Wang <wangxi11 at huawei.com>; Weihang Li <liweihang at huawei.com>; linux-rdma at vger.kernel.org; linux-kernel at 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 at kaspersky.com> wrote:

> From: Alexander Chesnokov <Alexander.Chesnokov at 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 at vger.kernel.org
> Suggested-by: David Laight <david.laight.linux at gmail.com>
> Signed-off-by: Alexander Chesnokov <Alexander.Chesnokov at 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 at 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;