From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f48.google.com (mail-wr1-f48.google.com [209.85.221.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id ACD0A382286 for ; Thu, 9 Jul 2026 15:28:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.48 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783610886; cv=none; b=OwLLq/WfF0NwdpqC2YtgiiYlyoV5RJ7m4KlX1h80t2oWhixNCV93YJedvNyPXEotOZAgxvfViSUGMURnY4A1on9nvPvyp9/agg9R64T0Q802hui+DrHCQ2heDyJoyBbirYRUeJwLcKS0VulqrO2ECrVX3Gd2uZ4LwcKKn+59Mj8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783610886; c=relaxed/simple; bh=gWk0Tx1PpSkQ7SrrEuYSkz1J6FwF7G6dNVcAD48RLZU=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=sN8U7ym5gS3WqI5gXtEw2mHCNkHY2YtA31REgWVdo5bmWF7K2HV7Mw/EDtr5uSWCRhpFBiMGtqu5uEZ78hVXNQFYjRISIG6Dj48tetA/7Mk5/I2RiEvSx6i3hRmgpjbmP61Wk14p+d1GOSGU05siSCf5eO6loq0reYQjqMv8x4Q= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=O2zplw0o; arc=none smtp.client-ip=209.85.221.48 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="O2zplw0o" Received: by mail-wr1-f48.google.com with SMTP id ffacd0b85a97d-47df440fcd5so13040f8f.3 for ; Thu, 09 Jul 2026 08:28:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1783610883; x=1784215683; darn=vger.kernel.org; h=content-transfer-encoding:content-type:mime-version:references :in-reply-to:message-id:subject:cc:to:from:date:from:to:cc:subject :date:message-id:reply-to:content-type; bh=CHbf130yEa4XzJ/mR051Bre42Fa2Qf6EqrRM78ycRyA=; b=O2zplw0opYDrs9XEFRoiSuNPe4G5TK8RLytwyhRA38cvVChmfrlJZY2pXxvI8fMak6 6tPINHKNR4Gp8RbzuXritr2f7L+hq/gWKOpaDDOFY9DaBlZE13EqgiFPhOODB6w6ZOJx 3Jgx1boyO6psQzSsJoULhaUO85R9oo0Z4vV7UUo5FHbYExmbbf73KnbEp3SUUFH+YPWi v3BVKiRiYcxJPLe5ia4sp9vC788x8wq62cepvyeAXvulCpcr8G2czVPgYxcCbqrzIwCu 6hXKYAMEMdpGeX+gdTG2HqshtrpnEb7MpXCon+blToWhbkX56zGRCu+WKuAqGLRpD1HR GSSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1783610883; x=1784215683; h=content-transfer-encoding:content-type:mime-version:references :in-reply-to:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=CHbf130yEa4XzJ/mR051Bre42Fa2Qf6EqrRM78ycRyA=; b=DWDyzD/bCJk+bBMJsZ1+1I0Rap9x8e/68QX0G3OjSO/LfGCGA9XTaHm96TwwKYwp6j qsIvCVHskMKKnKiwr4LRWCrVxUzJxX0ZpwXMrkLejlX5AaYJ0gO8bPuddxf9/fpUfKyT i2giLJttxkVxQ6R9olJL1GF7UOnKMCPds7BYdddItKN+P0hOelxkoJaXgw5wHr8/AnyW TpG+oZX5hTjPQ+OEMdnE5qMVvSz5tCoGh1f0TV8ivMB0g0ZyP7WWnviNhgTri3cEAF8M aLwHgqjqIIGbeWGrydyM18TkG6O7yrg/IbxOw6WEoA90FfzYcSXTxqezLAx9eglVakG2 7Rfg== X-Forwarded-Encrypted: i=1; AHgh+RqKJG3Vx7xLzElau/lbvc4ISG8FzSwdFjtGguTXLzgwOcIQ/NWQiB7X5KbPbpJ7hwBdqvrO3PABIynWYRM=@vger.kernel.org X-Gm-Message-State: AOJu0YzCUbUDBnOq/G6HterJVMK3ECRIDEGlHUiL8WY1h2gGO276ImO0 nYTNPVhTJYkOLKsmDjjwnP6+XzTj0/E7OnmD3+GkDPm8U4uD7Imaw3dA X-Gm-Gg: AfdE7cmOYsf8SpOaKA4BRGhS2hUzgXO2IM24TSNv5EakQYYz3ncDWSaLu+txRW3wyI4 e0t9LExg1mzpms4vXUySFybEgVmTPlOW6Bhg5Q+gn+EBQ8wh3Kb3WjbEcJFp/LzyemUAtJDEgLV SWgXrKrEmkoUHZtTHpWl3rJ0FqruXbFP99fxBXZ9IpzWd9fj/HUJoqUbJP8lmvEAOknX9ZR4jO5 Ngcqw8UwttPUR51rPowF/wBtKLi5n5DzqcK3GAPR+nDLFJv5EK4r8JvbDv/P2lkHBi46hbimXdJ +IaNKS2U9DW84q86flSoOA4DzJ+aK9NpL4B9VJ33WYQ9zew15MNpS5Maln9N3WIBQlzC8ZBoboU rsKeEfCzvMUPTmn0pNyWVVP1bzSWz8mYbNOGyHLhnXwqMaXIOKdkcxcu27xGFNxwQja2+zep1H7 Pvh32IYsX7jVYgN17tNq6EfNwqnJ7f+D/8r4LC143JkKHu+w== X-Received: by 2002:a05:6000:18a3:b0:47d:ef25:ff3b with SMTP id ffacd0b85a97d-47df0812ef6mr8098275f8f.49.1783610882799; Thu, 09 Jul 2026 08:28:02 -0700 (PDT) Received: from pumpkin (host-92-21-50-228.as13285.net. [92.21.50.228]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-47aa039ae44sm49942587f8f.23.2026.07.09.08.28.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 09 Jul 2026 08:28:02 -0700 (PDT) Date: Thu, 9 Jul 2026 16:27:59 +0100 From: David Laight To: Alexander Chesnokov Cc: "xuhaoyue1@hisilicon.com" , "lvc-project@linuxtesting.org" , Oleg Kazakov , Pavel Zhigulin , "stable@vger.kernel.org" , Wenpeng Liang , Jason Gunthorpe , Leon Romanovsky , Xi Wang , Weihang Li , "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() Message-ID: <20260709162759.1d836699@pumpkin> In-Reply-To: <24c0a3cf43074b37bb1c9c321a73f470@kaspersky.com> References: <20260707140938.3106919-1-Alexander.Chesnokov@kaspersky.com> <20260708092146.3325855-1-Alexander.Chesnokov@kaspersky.com> <20260708181941.1ad1e112@pumpkin> <24c0a3cf43074b37bb1c9c321a73f470@kaspersky.com> X-Mailer: Claws Mail 4.1.1 (GTK 3.24.38; arm-unknown-linux-gnueabihf) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Thu, 9 Jul 2026 04:56:56 +0000 Alexander Chesnokov 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 > Sent: Wednesday, July 8, 2026 8:20 PM > To: Alexander Chesnokov > Cc: xuhaoyue1@hisilicon.com; lvc-project@linuxtesting.org; Oleg Kazakov ; Pavel Zhigulin ; stable@vger.kernel.org; Wenpeng Liang ; Jason Gunthorpe ; Leon Romanovsky ; Xi Wang ; Weihang Li ; 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 > wrote: > > > From: Alexander Chesnokov > > > > 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 > > Signed-off-by: Alexander Chesnokov > > > > --- > > 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; >