From: Alexander Chesnokov <Alexander.Chesnokov@kaspersky.com>
To: David Laight <david.laight.linux@gmail.com>
Cc: "xuhaoyue1@hisilicon.com" <xuhaoyue1@hisilicon.com>,
"lvc-project@linuxtesting.org" <lvc-project@linuxtesting.org>,
Oleg Kazakov <Oleg.Kazakov@kaspersky.com>,
Pavel Zhigulin <Pavel.Zhigulin@kaspersky.com>,
"stable@vger.kernel.org" <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-rdma@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: RE: [PATCH v2] RDMA/hns: Fix arithmetic overflow in hns_roce_v2_set_hem()
Date: Thu, 9 Jul 2026 04:56:56 +0000 [thread overview]
Message-ID: <24c0a3cf43074b37bb1c9c321a73f470@kaspersky.com> (raw)
In-Reply-To: <20260708181941.1ad1e112@pumpkin>
> 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@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;
next prev parent reply other threads:[~2026-07-09 4:57 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-07 14:09 [PATCH] RDMA/hns: Fix arithmetic overflow in hns_roce_v2_set_hem() Alexander.Chesnokov
2026-07-07 19:49 ` David Laight
2026-07-08 9:21 ` [PATCH v2] " Alexander.Chesnokov
2026-07-08 15:54 ` Leon Romanovsky
2026-07-08 17:19 ` David Laight
2026-07-09 4:56 ` Alexander Chesnokov [this message]
2026-07-09 15:27 ` David Laight
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=24c0a3cf43074b37bb1c9c321a73f470@kaspersky.com \
--to=alexander.chesnokov@kaspersky.com \
--cc=Oleg.Kazakov@kaspersky.com \
--cc=Pavel.Zhigulin@kaspersky.com \
--cc=david.laight.linux@gmail.com \
--cc=jgg@ziepe.ca \
--cc=leon@kernel.org \
--cc=liangwenpeng@huawei.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=liweihang@huawei.com \
--cc=lvc-project@linuxtesting.org \
--cc=stable@vger.kernel.org \
--cc=wangxi11@huawei.com \
--cc=xuhaoyue1@hisilicon.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox