Linux RDMA and InfiniBand development
 help / color / mirror / Atom feed
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;


  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