| Message ID | 20231130094656.894412-1-lishifeng@sangfor.com.cn |
|---|---|
| State | New |
| Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org>
Delivered-To: ouuuleilei@gmail.com
Received: by 2002:a59:bcd1:0:b0:403:3b70:6f57 with SMTP id r17csp270271vqy;
Thu, 30 Nov 2023 01:57:17 -0800 (PST)
X-Google-Smtp-Source:
AGHT+IHzg3QuftQ226irTmuWHjluXHUXftyYQIzNlOyLhN6C6oDQy6Oet/NFK9iq8qV2rZKbU/Vb
X-Received: by 2002:a05:6a00:8d3:b0:6cb:e246:93ec with SMTP id
s19-20020a056a0008d300b006cbe24693ecmr32042340pfu.15.1701338236930;
Thu, 30 Nov 2023 01:57:16 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; t=1701338236; cv=none;
d=google.com; s=arc-20160816;
b=EIG9qpAoIUZyB+Arwp1cMoqEOn4zqh1nmc2zCX1cBqkiUaehyqUxap8ot4iSTYAxdW
bSHKMcTKFFqtVwVWT2g8waUSMjTKve3Hkk9uy2yxpmDvWgRDwP0HYiww6gQsfvLasZeA
DZCVWipKxDDDGZW3wbGoOceDq3YGRScrk3vm+Go+KFqbTVp1wQmOom8CIfFhuXkN5pSj
BUebGexm1wDNq+YY7WHFLtNRqBGCVwVTlxnOrrshr0wB5Lu6bLB6/DEqELgP3Schok3d
cXKiLvhXNoNkKVmxDjg3QeezHk2QsPV4HvMvv5IysyliotprWwQJ3NsjiJCuLN8/SkyZ
Pe0w==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com;
s=arc-20160816;
h=list-id:precedence:content-transfer-encoding:mime-version
:message-id:date:subject:cc:to:from;
bh=0uvAOVUJ064/T5yypOPqJY+z3sCk3f8wwvV7PUTaqyg=;
fh=Iu+AnBRt1wX0Ca+IsMscr83HgYH1OrIy36KSe9otW+w=;
b=qF0RulGlC6yC81NG9+oWvbNOwLNocYrTkhWk6URdMLjTowye6SgYvLk8KY2Jhr7MRP
rFqdwwVRSOHonLu2rjLyBueO99Ik7N6IHg0VDIIMSF6oYYPjYUG75ZR5nadHeokpGM5W
FrlqEQQ1rF+iZ5FwsiGGgevZCOX1YI0XtwTyVstDWb1r7v6Ja3MQzbItbUiFC1CoydAn
DFYj0mBtEuXF/fsKWMXURxm/4dgGjIkZcCfC071qizCWaknBTfSEe9c0y6bTMhMghrn4
jvnmELYZ2oz2MuQESvUOAudfTu78e6xaPxv/9RSmtGBMZAOfjn9M6MBtrY8n56oK4+3E
++Ag==
ARC-Authentication-Results: i=1; mx.google.com;
spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org
designates 2620:137:e000::3:2 as permitted sender)
smtp.mailfrom=linux-kernel-owner@vger.kernel.org;
dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=sangfor.com.cn
Received: from agentk.vger.email (agentk.vger.email. [2620:137:e000::3:2])
by mx.google.com with ESMTPS id
fd3-20020a056a002e8300b006cdd0109832si935113pfb.10.2023.11.30.01.57.16
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Thu, 30 Nov 2023 01:57:16 -0800 (PST)
Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org
designates 2620:137:e000::3:2 as permitted sender)
client-ip=2620:137:e000::3:2;
Authentication-Results: mx.google.com;
spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org
designates 2620:137:e000::3:2 as permitted sender)
smtp.mailfrom=linux-kernel-owner@vger.kernel.org;
dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=sangfor.com.cn
Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0])
by agentk.vger.email (Postfix) with ESMTP id A7887803A41B;
Thu, 30 Nov 2023 01:57:13 -0800 (PST)
X-Virus-Status: Clean
X-Virus-Scanned: clamav-milter 0.103.11 at agentk.vger.email
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
id S231843AbjK3J5B (ORCPT <rfc822;ruipengqi7@gmail.com> + 99 others);
Thu, 30 Nov 2023 04:57:01 -0500
Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56914 "EHLO
lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
with ESMTP id S229550AbjK3J47 (ORCPT
<rfc822;linux-kernel@vger.kernel.org>);
Thu, 30 Nov 2023 04:56:59 -0500
X-Greylist: delayed 573 seconds by postgrey-1.37 at lindbergh.monkeyblade.net;
Thu, 30 Nov 2023 01:57:03 PST
Received: from mail-m25476.xmail.ntesmail.com (mail-m25476.xmail.ntesmail.com
[103.129.254.76])
by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A1E859A;
Thu, 30 Nov 2023 01:57:03 -0800 (PST)
Received: from ubuntu.localdomain (unknown [111.222.250.119])
by mail-m12750.qiye.163.com (Hmail) with ESMTPA id 5D1DAF20542;
Thu, 30 Nov 2023 17:46:59 +0800 (CST)
From: Shifeng Li <lishifeng@sangfor.com.cn>
To: saeedm@nvidia.com, leon@kernel.org, davem@davemloft.net,
edumazet@google.com, kuba@kernel.org, pabeni@redhat.com,
ogerlitz@mellanox.com
Cc: netdev@vger.kernel.org, linux-rdma@vger.kernel.org,
linux-kernel@vger.kernel.org, dinghui@sangfor.com.cn,
lishifeng1992@126.com, Shifeng Li <lishifeng@sangfor.com.cn>
Subject: [PATCH] net/mlx5e: Fix slab-out-of-bounds in
mlx5_query_nic_vport_mac_list()
Date: Thu, 30 Nov 2023 01:46:56 -0800
Message-Id: <20231130094656.894412-1-lishifeng@sangfor.com.cn>
X-Mailer: git-send-email 2.25.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-HM-Spam-Status: e1kfGhgUHx5ZQUpXWQgPGg8OCBgUHx5ZQUlOS1dZFg8aDwILHllBWSg2Ly
tZV1koWUFITzdXWS1ZQUlXWQ8JGhUIEh9ZQVlCSBhOVkkdQ0pPTEhNTRlISlUTARMWGhIXJBQOD1
lXWRgSC1lBWUpKSlVJSUlVSU5LVUpKQllXWRYaDxIVHRRZQVlPS0hVSk1PSUxOVUpLS1VKQktLWQ
Y+
X-HM-Tid: 0a8c1f9fddd3b21dkuuu5d1daf20542
X-HM-MType: 1
X-HM-Sender-Digest: e1kMHhlZQR0aFwgeV1kSHx4VD1lBWUc6OjI6Sjo4Sjw#HhA3HgsVIS5L
OTowCzFVSlVKTEtKSEhMTUlLT0NMVTMWGhIXVRcSCBMSHR4VHDsIGhUcHRQJVRgUFlUYFUVZV1kS
C1lBWUpKSlVJSUlVSU5LVUpKQllXWQgBWUFISEpNNwY+
X-Spam-Status: No,
score=-0.8 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS,
MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE
autolearn=unavailable autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on agentk.vger.email
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
X-Greylist: Sender passed SPF test,
not delayed by milter-greylist-4.6.4 (agentk.vger.email [0.0.0.0]);
Thu, 30 Nov 2023 01:57:13 -0800 (PST)
X-getmail-retrieved-from-mailbox: INBOX
X-GMAIL-THRID: 1783982442786738650
X-GMAIL-MSGID: 1783982442786738650
|
| Series |
net/mlx5e: Fix slab-out-of-bounds in mlx5_query_nic_vport_mac_list()
|
|
Commit Message
Shifeng Li
Nov. 30, 2023, 9:46 a.m. UTC
Out_sz that the size of out buffer is calculated using query_nic_vport
_context_in structure when driver query the MAC list. However query_nic
_vport_context_in structure is smaller than query_nic_vport_context_out.
When allowed_list_size is greater than 96, calling ether_addr_copy() will
trigger an slab-out-of-bounds.
[ 1170.055866] BUG: KASAN: slab-out-of-bounds in mlx5_query_nic_vport_mac_list+0x481/0x4d0 [mlx5_core]
[ 1170.055869] Read of size 4 at addr ffff88bdbc57d912 by task kworker/u128:1/461
[ 1170.055870]
[ 1170.055932] Workqueue: mlx5_esw_wq esw_vport_change_handler [mlx5_core]
[ 1170.055936] Call Trace:
[ 1170.055949] dump_stack+0x8b/0xbb
[ 1170.055958] print_address_description+0x6a/0x270
[ 1170.055961] kasan_report+0x179/0x2c0
[ 1170.056061] mlx5_query_nic_vport_mac_list+0x481/0x4d0 [mlx5_core]
[ 1170.056162] esw_update_vport_addr_list+0x2c5/0xcd0 [mlx5_core]
[ 1170.056257] esw_vport_change_handle_locked+0xd08/0x1a20 [mlx5_core]
[ 1170.056377] esw_vport_change_handler+0x6b/0x90 [mlx5_core]
[ 1170.056381] process_one_work+0x65f/0x12d0
[ 1170.056383] worker_thread+0x87/0xb50
[ 1170.056390] kthread+0x2e9/0x3a0
[ 1170.056394] ret_from_fork+0x1f/0x40
Fixes: e16aea2744ab ("net/mlx5: Introduce access functions to modify/query vport mac lists")
Cc: Ding Hui <dinghui@sangfor.com.cn>
Signed-off-by: Shifeng Li <lishifeng@sangfor.com.cn>
---
drivers/net/ethernet/mellanox/mlx5/core/vport.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Comments
On Thu, Nov 30, 2023 at 01:46:56AM -0800, Shifeng Li wrote: > Out_sz that the size of out buffer is calculated using query_nic_vport > _context_in structure when driver query the MAC list. However query_nic > _vport_context_in structure is smaller than query_nic_vport_context_out. > When allowed_list_size is greater than 96, calling ether_addr_copy() will > trigger an slab-out-of-bounds. > > [ 1170.055866] BUG: KASAN: slab-out-of-bounds in mlx5_query_nic_vport_mac_list+0x481/0x4d0 [mlx5_core] > [ 1170.055869] Read of size 4 at addr ffff88bdbc57d912 by task kworker/u128:1/461 > [ 1170.055870] > [ 1170.055932] Workqueue: mlx5_esw_wq esw_vport_change_handler [mlx5_core] > [ 1170.055936] Call Trace: > [ 1170.055949] dump_stack+0x8b/0xbb > [ 1170.055958] print_address_description+0x6a/0x270 > [ 1170.055961] kasan_report+0x179/0x2c0 > [ 1170.056061] mlx5_query_nic_vport_mac_list+0x481/0x4d0 [mlx5_core] > [ 1170.056162] esw_update_vport_addr_list+0x2c5/0xcd0 [mlx5_core] > [ 1170.056257] esw_vport_change_handle_locked+0xd08/0x1a20 [mlx5_core] > [ 1170.056377] esw_vport_change_handler+0x6b/0x90 [mlx5_core] > [ 1170.056381] process_one_work+0x65f/0x12d0 > [ 1170.056383] worker_thread+0x87/0xb50 > [ 1170.056390] kthread+0x2e9/0x3a0 > [ 1170.056394] ret_from_fork+0x1f/0x40 > > Fixes: e16aea2744ab ("net/mlx5: Introduce access functions to modify/query vport mac lists") > Cc: Ding Hui <dinghui@sangfor.com.cn> > Signed-off-by: Shifeng Li <lishifeng@sangfor.com.cn> Hi, I am unsure how you calculated the 96 figure above. But in any case I agree that the cited patch introduced the mismatch that you describe. Reviewed-by: Simon Horman <horms@kernel.org>
On 2023/12/4 1:50, Simon Horman wrote: > On Thu, Nov 30, 2023 at 01:46:56AM -0800, Shifeng Li wrote: >> Out_sz that the size of out buffer is calculated using query_nic_vport >> _context_in structure when driver query the MAC list. However query_nic >> _vport_context_in structure is smaller than query_nic_vport_context_out. >> When allowed_list_size is greater than 96, calling ether_addr_copy() will >> trigger an slab-out-of-bounds. >> >> [ 1170.055866] BUG: KASAN: slab-out-of-bounds in mlx5_query_nic_vport_mac_list+0x481/0x4d0 [mlx5_core] >> [ 1170.055869] Read of size 4 at addr ffff88bdbc57d912 by task kworker/u128:1/461 >> [ 1170.055870] >> [ 1170.055932] Workqueue: mlx5_esw_wq esw_vport_change_handler [mlx5_core] >> [ 1170.055936] Call Trace: >> [ 1170.055949] dump_stack+0x8b/0xbb >> [ 1170.055958] print_address_description+0x6a/0x270 >> [ 1170.055961] kasan_report+0x179/0x2c0 >> [ 1170.056061] mlx5_query_nic_vport_mac_list+0x481/0x4d0 [mlx5_core] >> [ 1170.056162] esw_update_vport_addr_list+0x2c5/0xcd0 [mlx5_core] >> [ 1170.056257] esw_vport_change_handle_locked+0xd08/0x1a20 [mlx5_core] >> [ 1170.056377] esw_vport_change_handler+0x6b/0x90 [mlx5_core] >> [ 1170.056381] process_one_work+0x65f/0x12d0 >> [ 1170.056383] worker_thread+0x87/0xb50 >> [ 1170.056390] kthread+0x2e9/0x3a0 >> [ 1170.056394] ret_from_fork+0x1f/0x40 >> >> Fixes: e16aea2744ab ("net/mlx5: Introduce access functions to modify/query vport mac lists") >> Cc: Ding Hui <dinghui@sangfor.com.cn> >> Signed-off-by: Shifeng Li <lishifeng@sangfor.com.cn> > > Hi, > > I am unsure how you calculated the 96 figure above. > But in any case I agree that the cited patch introduced > the mismatch that you describe. > out_sz = MLX5_ST_SZ_BYTES(query_nic_vport_context_in) + req_list_size * MLX5_ST_SZ_BYTES(mac_address_layout) = 0x80/8 + 128 * 0x40/8 = 0x410 (bytes) nic_vport_ctx = MLX5_ADDR_OF(query_nic_vport_context_out, out, nic_vport_context) = 0x880/8 = 0x110 (bytes) mac_addr = MLX5_ADDR_OF(nic_vport_context, nic_vport_ctx, current_uc_mac_address[96]) + 2 = 0x110 + 96 * 8 + 2 = 0x412 (bytes) When i is 96, the mac_addr offset is 0x412 but the out_sz is 0x410. And that will trigger an slab-out-of-bounds. Thanks. > Reviewed-by: Simon Horman <horms@kernel.org>
On Mon, Dec 04, 2023 at 10:30:14AM +0800, Shifeng Li wrote: > On 2023/12/4 1:50, Simon Horman wrote: > > On Thu, Nov 30, 2023 at 01:46:56AM -0800, Shifeng Li wrote: > > > Out_sz that the size of out buffer is calculated using query_nic_vport > > > _context_in structure when driver query the MAC list. However query_nic > > > _vport_context_in structure is smaller than query_nic_vport_context_out. > > > When allowed_list_size is greater than 96, calling ether_addr_copy() will > > > trigger an slab-out-of-bounds. > > > > > > [ 1170.055866] BUG: KASAN: slab-out-of-bounds in mlx5_query_nic_vport_mac_list+0x481/0x4d0 [mlx5_core] > > > [ 1170.055869] Read of size 4 at addr ffff88bdbc57d912 by task kworker/u128:1/461 > > > [ 1170.055870] > > > [ 1170.055932] Workqueue: mlx5_esw_wq esw_vport_change_handler [mlx5_core] > > > [ 1170.055936] Call Trace: > > > [ 1170.055949] dump_stack+0x8b/0xbb > > > [ 1170.055958] print_address_description+0x6a/0x270 > > > [ 1170.055961] kasan_report+0x179/0x2c0 > > > [ 1170.056061] mlx5_query_nic_vport_mac_list+0x481/0x4d0 [mlx5_core] > > > [ 1170.056162] esw_update_vport_addr_list+0x2c5/0xcd0 [mlx5_core] > > > [ 1170.056257] esw_vport_change_handle_locked+0xd08/0x1a20 [mlx5_core] > > > [ 1170.056377] esw_vport_change_handler+0x6b/0x90 [mlx5_core] > > > [ 1170.056381] process_one_work+0x65f/0x12d0 > > > [ 1170.056383] worker_thread+0x87/0xb50 > > > [ 1170.056390] kthread+0x2e9/0x3a0 > > > [ 1170.056394] ret_from_fork+0x1f/0x40 > > > > > > Fixes: e16aea2744ab ("net/mlx5: Introduce access functions to modify/query vport mac lists") > > > Cc: Ding Hui <dinghui@sangfor.com.cn> > > > Signed-off-by: Shifeng Li <lishifeng@sangfor.com.cn> > > > > Hi, > > > > I am unsure how you calculated the 96 figure above. > > But in any case I agree that the cited patch introduced > > the mismatch that you describe. > > > out_sz = MLX5_ST_SZ_BYTES(query_nic_vport_context_in) + req_list_size * MLX5_ST_SZ_BYTES(mac_address_layout) > = 0x80/8 + 128 * 0x40/8 = 0x410 (bytes) > > nic_vport_ctx = MLX5_ADDR_OF(query_nic_vport_context_out, out, nic_vport_context) > = 0x880/8 = 0x110 (bytes) > mac_addr = MLX5_ADDR_OF(nic_vport_context, nic_vport_ctx, current_uc_mac_address[96]) + 2 > = 0x110 + 96 * 8 + 2 > = 0x412 (bytes) > > When i is 96, the mac_addr offset is 0x412 but the out_sz is 0x410. > And that will trigger an slab-out-of-bounds. Thanks for the clarification, this looks good to me. > > Reviewed-by: Simon Horman <horms@kernel.org>
On 30 Nov 01:46, Shifeng Li wrote: >Out_sz that the size of out buffer is calculated using query_nic_vport >_context_in structure when driver query the MAC list. However query_nic >_vport_context_in structure is smaller than query_nic_vport_context_out. >When allowed_list_size is greater than 96, calling ether_addr_copy() will >trigger an slab-out-of-bounds. > >[ 1170.055866] BUG: KASAN: slab-out-of-bounds in mlx5_query_nic_vport_mac_list+0x481/0x4d0 [mlx5_core] >[ 1170.055869] Read of size 4 at addr ffff88bdbc57d912 by task kworker/u128:1/461 >[ 1170.055870] >[ 1170.055932] Workqueue: mlx5_esw_wq esw_vport_change_handler [mlx5_core] >[ 1170.055936] Call Trace: >[ 1170.055949] dump_stack+0x8b/0xbb >[ 1170.055958] print_address_description+0x6a/0x270 >[ 1170.055961] kasan_report+0x179/0x2c0 >[ 1170.056061] mlx5_query_nic_vport_mac_list+0x481/0x4d0 [mlx5_core] >[ 1170.056162] esw_update_vport_addr_list+0x2c5/0xcd0 [mlx5_core] >[ 1170.056257] esw_vport_change_handle_locked+0xd08/0x1a20 [mlx5_core] >[ 1170.056377] esw_vport_change_handler+0x6b/0x90 [mlx5_core] >[ 1170.056381] process_one_work+0x65f/0x12d0 >[ 1170.056383] worker_thread+0x87/0xb50 >[ 1170.056390] kthread+0x2e9/0x3a0 >[ 1170.056394] ret_from_fork+0x1f/0x40 > >Fixes: e16aea2744ab ("net/mlx5: Introduce access functions to modify/query vport mac lists") >Cc: Ding Hui <dinghui@sangfor.com.cn> >Signed-off-by: Shifeng Li <lishifeng@sangfor.com.cn> Applied to net-mlx5. Thanks, Saeed.
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/vport.c b/drivers/net/ethernet/mellanox/mlx5/core/vport.c index 5a31fb47ffa5..21753f327868 100644 --- a/drivers/net/ethernet/mellanox/mlx5/core/vport.c +++ b/drivers/net/ethernet/mellanox/mlx5/core/vport.c @@ -277,7 +277,7 @@ int mlx5_query_nic_vport_mac_list(struct mlx5_core_dev *dev, req_list_size = max_list_size; } - out_sz = MLX5_ST_SZ_BYTES(query_nic_vport_context_in) + + out_sz = MLX5_ST_SZ_BYTES(query_nic_vport_context_out) + req_list_size * MLX5_ST_SZ_BYTES(mac_address_layout); out = kvzalloc(out_sz, GFP_KERNEL);