From nobody Tue Sep 29 05:35:42 2026 Received: from mail-pf1-f171.google.com (mail-pf1-f171.google.com [209.85.210.171]) (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 C6B0942FCB9 for ; Tue, 11 Aug 2026 23:20:15 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.171 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786490418; cv=none; b=gASFdN+cUZsxkbtCWLIUdWcWKMOAaYEi7GCwrjcySRunw9UyVhREuy2d7pFzB/qKXPCu+sk3TVIWQd/uED/MCciDrbNd5NBB0eXJ2qAsUZtEsbZY6kkrSd/4mLdpplR0oQa3QluM3nyJ1x0OkAn7EDAp+bpWaHTlmVUew/aZf0Q= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786490418; c=relaxed/simple; bh=22nPeXdbupsRSm+fjl9Od2TafluxfMvurzDk9av37OY=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=bQbt/gJUN27kQ4sNkaAN/bDUA8t3lWUOPa2r5cS3PM6R0ukl8DpSi62Q52CVzsWmuGl4gIyf22QgISfwnVsabyjdjjz45kTVhiFurWZeFe5YqleSKE+VocfznpMf4o2QiE5e310M86K2h9fHMFjQX/+eWZUs5zqZzlQ8sLGv2QM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=fail (p=none dis=none) header.from=isslab.korea.ac.kr; spf=none smtp.mailfrom=isslab.korea.ac.kr; dkim=pass (2048-bit key) header.d=isslab-korea-ac-kr.20251104.gappssmtp.com header.i=@isslab-korea-ac-kr.20251104.gappssmtp.com header.b=xL+TXGow; arc=none smtp.client-ip=209.85.210.171 Authentication-Results: smtp.subspace.kernel.org; dmarc=fail (p=none dis=none) header.from=isslab.korea.ac.kr Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=isslab.korea.ac.kr Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=isslab-korea-ac-kr.20251104.gappssmtp.com header.i=@isslab-korea-ac-kr.20251104.gappssmtp.com header.b="xL+TXGow" Received: by mail-pf1-f171.google.com with SMTP id d2e1a72fcca58-84e84a6c4bfso418526b3a.1 for ; Tue, 11 Aug 2026 16:20:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isslab-korea-ac-kr.20251104.gappssmtp.com; s=20251104; t=1786490415; x=1787095215; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=Gk+a9mLjO1sFOyggqzNdg6aQdGam47r8W59+GEbhQOg=; b=xL+TXGowS1L3PRwf0Skkb9QnNKyeGM2QJZ+vH7Q1whwPXM3xZ5joolsH/ITZ8TFByI g11KItUyYz6dq5BkLcbHdJOP2TuKQkUpPdwGGUxttjyvj7x7T7sNNBVU5f5nhdCY7TbG GPewq1I1uLY8EJAw2h6c5biItomxjlg2toQrGppjQ/f5PUwm76NGncPk3hCg8GROwrGy v6+1GeNW5fJFeHsOsGzfcicroTvYxA+eFQbAx7C+MWUa0LGFiB33ef0FLokmMJ+fB39c la1IOM5lq/8XBU1qRKn1RpQJuMXaOZn8T03Z+hk3Jqtq37DVcAbZDRCPsfnc7HfCNe0E 3eow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786490415; x=1787095215; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=Gk+a9mLjO1sFOyggqzNdg6aQdGam47r8W59+GEbhQOg=; b=Sj2iM8cQoudu2/nEPU7Fkfe28rMSzfQ8d4hu1UyNt5GMq/Pub1CUtgA7YaaClG3rHD 8WGOn279/vqsLS8PPxTH5Wue9C0GVgyFGHhYKLRydRMfJvvqGXaT1fkKBR8tXFTU++09 VOlF2rlSc/kdRgz/xxjwmYFGOXvTi74ElyUJY7j6BfDfs5WLpZx2IpUYLkYzBNholYsW iAd2zSJvZa5I2DOHnDHcaKeb10NRA9Vjer4fxvVRk9R/ErU8/LRSmqtBREvMZHBV4ISM MVJvT/RFBTqk61sF8oo1oedYIghJxe1KAqq3pUwijW+pJs+7xxyCat+jFACyNITslDqr kRtQ== X-Forwarded-Encrypted: i=1; AHgh+RpsqDMX9xozL5U+xYXJHYkNNulsRgbNTNYdpm2k4wGg1OYnEXT5QrmbHvf6EzByb01ngCitSsQvtDZq1LU=@vger.kernel.org X-Gm-Message-State: AOJu0YyjEpHcAV7OsAimKQgTlBBTi/7m2qGAnA9wBPpY2kAAUsltCda0 /d6llHtH//3HVRkhOzD6YJ6qB6H2k3byKlHmUD+pOyZTEdl1EYomwUpesIEliaq/A1Q= X-Gm-Gg: AR+sD130MYvsrLkdTKnExMuL4rWxhGQ8by8bqdx0mU9aPsil5eKa0M0JaudftCjfx+z loqenOA9+iccs6yMokV8mwjgKXdBk0TAtMACHRSWCN5g+MZDQOYXoKq4AOZvfexzMou/D2Vir/Q eh+raqsbBznzEkiYXfaN5mDzwshUOPAxHYm1OOTrHEQdSegeBpMiQy7HIivp4muq68KiUQUr4yj 1NKEGgVl55MshuSI4mURRR1ZvKzHvisJDCAIZBGm5iuFH+0drhyiaD7WRQi/tjLokZ2lnlJtSbl kdnGZJOryPuAwA3X1ZxtYdRIuI/Ywi8XApGspgQ7bHu1GtEFpKc2x3ABGEIZtaBiK6/sTyvGTWF AFkcCNl+nBldz883ZRnigU0E5RQ0nR3zKXFgnlu5evkuLKNtPL8+cTETXY6FSPG/0d0nK49wVaI QJWEngiIk0crWWxTlPmjO5XyWnttrtX98KevaWkTiuppHKfBrQQkDUJUqnQ/dzOqcf2XSDGOE28 WuusT2SCfQ= X-Received: by 2002:a05:6a00:1c9e:b0:84a:2b96:5986 with SMTP id d2e1a72fcca58-84fafa314a0mr4134236b3a.8.1786490414938; Tue, 11 Aug 2026 16:20:14 -0700 (PDT) Received: from yhlee-960QFG.Davolink ([2406:5900:1044:110c:365f:6c09:b402:1986]) by smtp.gmail.com with ESMTPSA id 41be03b00d2f7-cbedbac8842sm1177810a12.30.2026.08.11.16.20.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 11 Aug 2026 16:20:14 -0700 (PDT) From: Yehyeong Lee To: alibuda@linux.alibaba.com, dust.li@linux.alibaba.com, sidraya@linux.ibm.com, wenjia@linux.ibm.com, kuba@kernel.org, davem@davemloft.net, edumazet@google.com, pabeni@redhat.com Cc: leitao@debian.org, horms@kernel.org, mjambigi@linux.ibm.com, tonylu@linux.alibaba.com, guwen@linux.alibaba.com, guangguan.wang@linux.alibaba.com, kees@kernel.org, gustavoars@kernel.org, netdev@vger.kernel.org, linux-rdma@vger.kernel.org, linux-s390@vger.kernel.org, linux-hardening@vger.kernel.org, linux-kernel@vger.kernel.org, Yehyeong Lee , stable@vger.kernel.org Subject: [PATCH net v6 1/3] net/smc: fix use-after-free of the LLC qentry in smc_llc_srv_add_link() Date: Wed, 12 Aug 2026 08:19:00 +0900 Message-ID: <20260811231902.47089-2-yhlee@isslab.korea.ac.kr> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260811231902.47089-1-yhlee@isslab.korea.ac.kr> References: <20260811231902.47089-1-yhlee@isslab.korea.ac.kr> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" smc_llc_srv_add_link() keeps add_llc pointing into the queue entry: add_llc =3D &qentry->msg.add_link; smc_llc.c:1482 ... smc_llc_save_add_link_info(link_new, add_llc); smc_llc.c:1494 smc_llc_flow_qentry_del(&lgr->llc_flow_lcl); smc_llc.c:1495 ... u8 *llc_msg =3D smc_link_shared_v2_rxbuf(link) ? (u8 *)lgr->wr_rx_buf_v2 : (u8 *)add_llc; smc_llc.c:1504 smc_llc_save_add_link_rkeys(link, link_new, llc_msg); smc_llc.c:1506 smc_llc_flow_qentry_del() kfree()s the entry, so on a link without a shared v2 receive buffer the pointer handed to smc_llc_save_add_link_rkeys() is already freed. Before the Fixes: commit that branch always used lgr->wr_rx_buf_v2 and add_llc was not used after the free. Reproduced on an unpatched tree over rxe, with KASAN, kasan_multi_shot and a link forced to max_recv_sge =3D=3D 1: the entry is freed and read by the same call, and the freeing frame is smc_llc_srv_add_link() itself. [ 2.523161] BUG: KASAN: slab-use-after-free in smc_llc_save_add_link_r= keys+0x333/0x350 [ 2.523499] Read of size 2 at addr ffff8880052194de by task kworker/0:= 1/11 [ 2.523789]=20 [ 2.523862] CPU: 0 UID: 0 PID: 11 Comm: kworker/0:1 Not tainted 7.2.0-= rc5-p0-g2c9dd296545d #35 PREEMPT(lazy)=20 [ 2.523865] Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arc= h_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 2.523866] Workqueue: smc_hs_wq smc_listen_work [ 2.523869] Call Trace: [ 2.523870] [ 2.523871] dump_stack_lvl+0x53/0x70 [ 2.523872] print_report+0xd0/0x630 [ 2.523874] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 2.523876] ? smc_llc_save_add_link_rkeys+0x333/0x350 [ 2.523878] kasan_report+0xce/0x100 [ 2.523879] ? smc_llc_save_add_link_rkeys+0x333/0x350 [ 2.523881] smc_llc_save_add_link_rkeys+0x333/0x350 [ 2.523883] ? smcr_buf_reg_lgr+0x2a4/0x660 [ 2.523885] smc_llc_srv_add_link+0xaa2/0x1e50 [ 2.523888] ? _printk+0xba/0xf0 [ 2.523897] ? __pfx_smc_llc_srv_add_link+0x10/0x10 [ 2.523899] ? down_write+0xb0/0x130 [ 2.523903] ? __pfx_down_write+0x10/0x10 [ 2.523905] smc_listen_work+0x489e/0x4d00 [ 2.523907] ? kmem_cache_free+0x1c6/0x3a0 [ 2.523911] ? __pfx_smc_listen_work+0x10/0x10 [ 2.523913] ? release_sock+0x148/0x1d0 [ 2.523915] ? smc_tcp_listen_work+0xb4f/0xfc0 [ 2.523917] ? _raw_spin_lock_irq+0x80/0xe0 [ 2.523918] ? __pfx__raw_spin_lock_irq+0x10/0x10 [ 2.523920] process_one_work+0x633/0x1030 [ 2.523922] ? assign_work+0x11d/0x370 [ 2.523924] worker_thread+0x45b/0xd10 [ 2.523926] ? __pfx_worker_thread+0x10/0x10 [ 2.523928] ? __pfx_worker_thread+0x10/0x10 [ 2.523929] kthread+0x2c6/0x3b0 [ 2.523931] ? recalc_sigpending+0x15c/0x1e0 [ 2.523934] ? __pfx_kthread+0x10/0x10 [ 2.523935] ret_from_fork+0x36e/0x5a0 [ 2.523937] ? __pfx_ret_from_fork+0x10/0x10 [ 2.523938] ? __switch_to+0x572/0xdd0 [ 2.523943] ? __pfx_kthread+0x10/0x10 [ 2.523944] ret_from_fork_asm+0x1a/0x30 [ 2.523947] [ 2.523948]=20 [ 2.531253] Allocated by task 48: [ 2.531399] kasan_save_stack+0x33/0x60 [ 2.531570] kasan_save_track+0x14/0x30 [ 2.531737] __kasan_kmalloc+0x8f/0xa0 [ 2.531905] __kmalloc_cache_noprof+0x158/0x370 [ 2.532100] smc_llc_enqueue+0x72/0x560 [ 2.532268] smc_wr_rx_tasklet_fn+0x474/0xa80 [ 2.532491] tasklet_action_common+0x20f/0x8a0 [ 2.532714] handle_softirqs+0x18e/0x590 [ 2.532886] do_softirq+0x3b/0x60 [ 2.533036] __local_bh_enable_ip+0x61/0x70 [ 2.533221] __alloc_skb+0x732/0x890 [ 2.533384] rxe_init_packet+0x16b/0x4f0 [ 2.533567] prepare_ack_packet+0xb8/0x830 [ 2.533760] rxe_receiver+0x495/0x96e0 [ 2.533933] do_work+0x144/0x470 [ 2.534078] process_one_work+0x633/0x1030 [ 2.534257] worker_thread+0x45b/0xd10 [ 2.534424] kthread+0x2c6/0x3b0 [ 2.534569] ret_from_fork+0x36e/0x5a0 [ 2.534737] ret_from_fork_asm+0x1a/0x30 [ 2.534907]=20 [ 2.534980] Freed by task 11: [ 2.535112] kasan_save_stack+0x33/0x60 [ 2.535279] kasan_save_track+0x14/0x30 [ 2.535444] kasan_save_free_info+0x3b/0x60 [ 2.535625] __kasan_slab_free+0x43/0x70 [ 2.535798] kfree+0x121/0x380 [ 2.535935] smc_llc_srv_add_link+0x9a8/0x1e50 [ 2.536128] smc_listen_work+0x489e/0x4d00 [ 2.536305] process_one_work+0x633/0x1030 [ 2.536482] worker_thread+0x45b/0xd10 [ 2.536652] kthread+0x2c6/0x3b0 [ 2.536794] ret_from_fork+0x36e/0x5a0 [ 2.536958] ret_from_fork_asm+0x1a/0x30 [ 2.537133]=20 [ 2.537205] The buggy address belongs to the object at ffff888005219480 [ 2.537205] which belongs to the cache kmalloc-96 of size 96 [ 2.537719] The buggy address is located 94 bytes inside of [ 2.537719] freed 96-byte region [ffff888005219480, ffff8880052194e0) [ 2.538216]=20 [ 2.538289] The buggy address belongs to the physical page: [ 2.538524] page: refcount:0 mapcount:0 mapping:0000000000000000 index= :0x0 pfn:0x5219 [ 2.538857] flags: 0x100000000000000(node=3D0|zone=3D1) [ 2.539066] page_type: f5(slab) [ 2.539210] raw: 0100000000000000 ffff888001041280 dead000000000122 00= 00000000000000 [ 2.539534] raw: 0000000000000000 0000000000200020 00000000f5000000 00= 00000000000000 [ 2.539863] page dumped because: kasan: bad access detected [ 2.540098]=20 [ 2.540170] Memory state around the buggy address: [ 2.540379] ffff888005219380: fc fc fc fc fc fc fc fc fc fc fc fc fc = fc fc fc [ 2.540684] ffff888005219400: fc fc fc fc fc fc fc fc fc fc fc fc fc = fc fc fc [ 2.540988] >ffff888005219480: fa fb fb fb fb fb fb fb fb fb fb fb fc = fc fc fc [ 2.541291] ^ [ 2.541548] ffff888005219500: 00 00 00 00 00 00 00 00 00 fc fc fc fc = fc fc fc [ 2.541857] ffff888005219580: 00 00 00 00 00 00 00 00 00 fc fc fc fc = fc fc fc The offset is past the 72-byte queue entry because the out-of-bounds read fixed by the next patch is on the same line; what this patch removes is the free at smc_llc_srv_add_link+0x9a8 happening before the read at +0xaa2. Detach the entry instead of freeing it there, and free it at the single exit label. The reject path has to detach as well, otherwise it would be freed twice. This changes only the lifetime of the entry. The same read still runs past its end until the next two patches bound it, so a backport wants all three. Fixes: 27ef6a9981fe ("net/smc: support SMC-R V2 for rdma devices with max_r= ecv_sge equals to 1") Cc: stable@vger.kernel.org Signed-off-by: Yehyeong Lee Reviewed-by: Sidraya Jayagond --- Changes since v5: return through the existing exit label. net/smc/smc_llc.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/net/smc/smc_llc.c b/net/smc/smc_llc.c index 954b2ff1815c..055a03eee5b5 100644 --- a/net/smc/smc_llc.c +++ b/net/smc/smc_llc.c @@ -1481,7 +1481,7 @@ int smc_llc_srv_add_link(struct smc_link *link, } add_llc =3D &qentry->msg.add_link; if (add_llc->hd.flags & SMC_LLC_FLAG_ADD_LNK_REJ) { - smc_llc_flow_qentry_del(&lgr->llc_flow_lcl); + smc_llc_flow_qentry_clr(&lgr->llc_flow_lcl); rc =3D -ENOLINK; goto out_err; } @@ -1492,7 +1492,8 @@ int smc_llc_srv_add_link(struct smc_link *link, lgr_new_t =3D SMC_LGR_ASYMMETRIC_PEER; } smc_llc_save_add_link_info(link_new, add_llc); - smc_llc_flow_qentry_del(&lgr->llc_flow_lcl); + /* add_llc still points into qentry, so only detach it here */ + smc_llc_flow_qentry_clr(&lgr->llc_flow_lcl); =20 rc =3D smc_ib_ready_link(link_new); if (rc) @@ -1512,14 +1513,14 @@ int smc_llc_srv_add_link(struct smc_link *link, rc =3D smc_llc_srv_conf_link(link, link_new, lgr_new_t); if (rc) goto out_err; - kfree(ini); - return 0; + goto out; out_err: if (link_new) { link_new->state =3D SMC_LNK_INACTIVE; smcr_link_clear(link_new, false); } out: + kfree(qentry); kfree(ini); if (send_req_add_link_resp) smc_llc_send_req_add_link_response(req_qentry); --=20 2.43.0 From nobody Tue Sep 29 05:35:42 2026 Received: from mail-pf1-f178.google.com (mail-pf1-f178.google.com [209.85.210.178]) (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 1E2DD42E8C0 for ; Tue, 11 Aug 2026 23:20:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.178 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786490425; cv=none; b=gRShR2oYNIS0sIZGSEUAGhaQj+9XHeEgL84pzjUYI6bBC4CpHTE+IpIAZadxVDWf/a4TRCNjT54mWXLWNbsJIqezTR7E7Wws6WrXM/KBRM5pv7LhaBz7vQOF+m0NuDuBkKziMeh/0r6gzZoLX/+KuObJ3n9jO2ymES5FiuuU070= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786490425; c=relaxed/simple; bh=ramlrnMJG12sU1HSKRzL6k/DNzPk28iC5T5uY9kAm5o=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=K3Gv5bL8SwYKhp23nThIrHSe60Bbnsq3BFstbzVVDxCodlXiL7fqTLH3lmSs53q301eEpUU8aMjPBgmnqUKy4Pzz6n0yCuEAwjw8/gwQLoW6Yjs7kUZLDNIf3x6xohOi05hPq5MEWgD4E139jzMpZabzoQxczcK98vl6Y4RaavM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=fail (p=none dis=none) header.from=isslab.korea.ac.kr; spf=none smtp.mailfrom=isslab.korea.ac.kr; dkim=pass (2048-bit key) header.d=isslab-korea-ac-kr.20251104.gappssmtp.com header.i=@isslab-korea-ac-kr.20251104.gappssmtp.com header.b=zo5xmlbe; arc=none smtp.client-ip=209.85.210.178 Authentication-Results: smtp.subspace.kernel.org; dmarc=fail (p=none dis=none) header.from=isslab.korea.ac.kr Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=isslab.korea.ac.kr Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=isslab-korea-ac-kr.20251104.gappssmtp.com header.i=@isslab-korea-ac-kr.20251104.gappssmtp.com header.b="zo5xmlbe" Received: by mail-pf1-f178.google.com with SMTP id d2e1a72fcca58-8486ac3f347so1542946b3a.1 for ; Tue, 11 Aug 2026 16:20:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isslab-korea-ac-kr.20251104.gappssmtp.com; s=20251104; t=1786490423; x=1787095223; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=PqM4RUHFJHYgsOUI3et1n95pYjRwiyC2guAXCJsd3iE=; b=zo5xmlbeC6APkEWF+G1XPa2Wl6vGEzTMo0LDtltgLuRXx5turDxF9MB+D6khH83WVS Oq5ChSXJK8KR7/f7PfhVAi0yH0NzW6Bg6qCAc2iZW+wMKk9j+LWpiz6ojtR+D4fdI8Km WEVF5WSFFaNzPrWOo9VrJ0jJEkt2n4ZGH3WExRdzt2OawT+HknBUi512Fep5PhaI63Dc 2iLLILJIAtdgRsKFY8Q6pStOqzvbAebOO2eMcxVTWy9uHAIDR/xMXjHc/gGygKHoiBfS 2yZWIRPA0NgsWLr6hygoi6b27hoKHx3Pya/7lyfqjyjiRkVZ0hHfpFFpw9vdGhQpuiWp awtg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786490423; x=1787095223; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=PqM4RUHFJHYgsOUI3et1n95pYjRwiyC2guAXCJsd3iE=; b=VTu5/XLbGP6cKgOwzcfA+iADh9w3ISciXiK47GTtVJtpZI9iBRHlkZzQdePn3+Vrt4 znISi72w0mumsY4geeF4g5+97ZTXdLrwZQ7u/t+SIzKlga55pxZPGkAvrgeY4VbPZDOA 8TETPEbh5rBjcjyYdyL9ef0yMRruCQpQJm2Z/UOij6KyaMia46pAeYsSureFwRHbMb9Y EDM3i5pfww8cg7SrZ4aStH3a5XT3XeOY46VyJf0YxuEiAXqBIXgjwGhW9PXDBdw87oVd 93tTC8bfA1tQTSZ0mhZRI3hjkRzlxqnwfO3XHG7vZp9lf/TyOxYTfVIsIhdmd0UzGF+y QyLA== X-Forwarded-Encrypted: i=1; AHgh+RphLrZEesHO38qfgf9vfya+3hSB3qiFe+dIXtlc562U5+jDwQn10GLz5Fuzi2Zq0Z5XCrB5KqfLFSQXaRM=@vger.kernel.org X-Gm-Message-State: AOJu0YzwiwXZ6cxjL2BxlHjkoge5y5UEOhgGUUrqsI6GhLkW6uQdmiP0 nVO88XarbjjfkG/LD9/jOdh0pJgbnjOlyefkDYKhKxigp7T412nK/T2djwBT29LMRaE= X-Gm-Gg: AR+sD11rOJOol6JlM+72JAX488/S6DSyJDSrldwnkN1KsuC1PPNv4IEvnbdEJZfduqN VRxsQIAmlI7YmyyOe/b2ewpmBytRFb5HJ6SdmfKkd8080Qbg9tpsDsAc3P3a5ggvO2j08SoUxIs 6o/On4SidTL/ymWPnbLIGvv46IkRV12lUfMG8DP+uPhD117BBmCh/gOVyo+6LRrb982gQbvil+J /QSZR1u3QuZUGIptQkhTrHDooB3IrKI4/11XfdFZ5GjXBwjZ4AVQSaGZVWNYIKAHvfcXH6H7k+e xE43g4t/N+Iwntinoqr8x8yYV7MS+Vitr2Js22PW+pHmXWAqMdoHPOMcotGz0H5vu1fvDHi6LKW 0mrFgji46siPJzI58nFBgskGdorz5o1LdzwrW3n9E+eteuGvYKM2vBUIaTgxFjHxid6/XhS4htS taPAF5zwPcukV/4D9Q8yYj1Xodu+4sLFMsJBdo3Fb+uIbXo2s4Mz1jhmBSbbWGrxgZixJJMs2Gi HUmaKosSVU= X-Received: by 2002:a05:6a20:9f93:b0:3b5:530d:d96d with SMTP id adf61e73a8af0-3cc3f8c2a31mr378177637.12.1786490423253; Tue, 11 Aug 2026 16:20:23 -0700 (PDT) Received: from yhlee-960QFG.Davolink ([2406:5900:1044:110c:365f:6c09:b402:1986]) by smtp.gmail.com with ESMTPSA id 41be03b00d2f7-cbedbac8842sm1177810a12.30.2026.08.11.16.20.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 11 Aug 2026 16:20:22 -0700 (PDT) From: Yehyeong Lee To: alibuda@linux.alibaba.com, dust.li@linux.alibaba.com, sidraya@linux.ibm.com, wenjia@linux.ibm.com, kuba@kernel.org, davem@davemloft.net, edumazet@google.com, pabeni@redhat.com Cc: leitao@debian.org, horms@kernel.org, mjambigi@linux.ibm.com, tonylu@linux.alibaba.com, guwen@linux.alibaba.com, guangguan.wang@linux.alibaba.com, kees@kernel.org, gustavoars@kernel.org, netdev@vger.kernel.org, linux-rdma@vger.kernel.org, linux-s390@vger.kernel.org, linux-hardening@vger.kernel.org, linux-kernel@vger.kernel.org, Yehyeong Lee , stable@vger.kernel.org Subject: [PATCH net v6 2/3] net/smc: bound the peer rkey counts in SMC-Rv2 LLC messages Date: Wed, 12 Aug 2026 08:19:01 +0900 Message-ID: <20260811231902.47089-3-yhlee@isslab.korea.ac.kr> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260811231902.47089-1-yhlee@isslab.korea.ac.kr> References: <20260811231902.47089-1-yhlee@isslab.korea.ac.kr> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On a link whose device has max_recv_sge =3D=3D 1 there is no shared v2 rece= ive buffer, and smc_llc_save_add_link_rkeys() takes the v2 extension from 44 bytes past the start of the queue entry's inline message: ext =3D (struct smc_llc_msg_add_link_v2_ext *)(llc_msg + SMC_WR_TX_SIZE); The entry is a 72-byte allocation and the extension starts at offset 68, so ext->num_rkeys at offset 94 is already past it. This happens on every SMC-Rv2 link addition, whatever the peer sends: [ 2.490065] BUG: KASAN: slab-out-of-bounds in smc_llc_save_add_link_rk= eys+0x333/0x350 [ 2.490431] Read of size 2 at addr ffff8880056406de by task smctest/106 [ 2.490709]=20 [ 2.490792] CPU: 0 UID: 0 PID: 106 Comm: smctest Not tainted 7.2.0-rc5= -p1-g77a5d9d9c99f #32 PREEMPT(lazy)=20 [ 2.490795] Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arc= h_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 2.490798] Call Trace: [ 2.490803] [ 2.490805] dump_stack_lvl+0x53/0x70 [ 2.490810] print_report+0xd0/0x630 [ 2.490828] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 2.490832] ? smc_llc_save_add_link_rkeys+0x333/0x350 [ 2.490834] kasan_report+0xce/0x100 [ 2.490836] ? smc_llc_save_add_link_rkeys+0x333/0x350 [ 2.490837] smc_llc_save_add_link_rkeys+0x333/0x350 [ 2.490839] ? smcr_buf_map_lgr+0x1bf/0x2b0 [ 2.490844] smc_llc_cli_add_link+0xca7/0x1e80 [ 2.490848] ? smc_llc_wait+0x355/0x810 [ 2.490850] ? __pfx_smc_llc_wait+0x10/0x10 [ 2.490851] ? __pfx_smc_llc_cli_add_link+0x10/0x10 [ 2.490853] ? __pfx_autoremove_wake_function+0x10/0x10 [ 2.490863] __smc_connect+0x3f5c/0x4980 [ 2.490873] ? __pfx_kernel_connect+0x10/0x10 [ 2.490888] ? __pfx___smc_connect+0x10/0x10 [ 2.490891] ? release_sock+0x148/0x1d0 [ 2.490894] smc_connect+0x42c/0x580 [ 2.490896] __sys_connect+0xfc/0x130 [ 2.490898] ? __pfx___sys_connect+0x10/0x10 [ 2.490900] ? handle_mm_fault+0x1a1/0x430 [ 2.490908] __x64_sys_connect+0x6d/0xb0 [ 2.490909] ? fpregs_assert_state_consistent+0x56/0xe0 [ 2.490917] do_syscall_64+0xf9/0x540 [ 2.490921] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 2.490924] RIP: 0033:0x421bb4 [ 2.490927] Code: ff f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 0= 0 00 00 00 90 f3 0f 1e fa 80 3d ad 34 09 00 00 74 13 b8 2a 00 00 00 0f 05 <= 48> 3d 00 f0 ff ff 77 4c c3 0f 1f 00 55 48 89 e5 48 83 ec 10 89 55 [ 2.490929] RSP: 002b:00007ffd473b01a8 EFLAGS: 00000202 ORIG_RAX: 0000= 00000000002a [ 2.490935] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 000000000= 0421bb4 [ 2.490936] RDX: 0000000000000010 RSI: 00007ffd473b01d0 RDI: 000000000= 0000003 [ 2.490937] RBP: 0000000000003930 R08: 0000000000000004 R09: 000000000= 0000000 [ 2.490938] R10: 00007ffd473b0f98 R11: 0000000000000202 R12: 000000000= 0000006 [ 2.490939] R13: 00007ffd473b0f87 R14: 0000000000000003 R15: 00007ffd4= 73b0f90 [ 2.490940] [ 2.490941]=20 [ 2.499545] Allocated by task 44: [ 2.499693] kasan_save_stack+0x33/0x60 [ 2.499860] kasan_save_track+0x14/0x30 [ 2.500026] __kasan_kmalloc+0x8f/0xa0 [ 2.500190] __kmalloc_cache_noprof+0x158/0x370 [ 2.500393] smc_llc_enqueue+0x72/0x560 [ 2.500559] smc_wr_rx_tasklet_fn+0x474/0xa80 [ 2.500747] tasklet_action_common+0x20f/0x8a0 [ 2.500945] handle_softirqs+0x18e/0x590 [ 2.501115] do_softirq+0x3b/0x60 [ 2.501266] __local_bh_enable_ip+0x61/0x70 [ 2.501446] __alloc_skb+0x732/0x890 [ 2.501604] rxe_init_packet+0x16b/0x4f0 [ 2.501783] prepare_ack_packet+0xb8/0x830 [ 2.501962] rxe_receiver+0x495/0x96e0 [ 2.502125] do_work+0x144/0x470 [ 2.502269] process_one_work+0x633/0x1030 [ 2.502450] worker_thread+0x45b/0xd10 [ 2.502617] kthread+0x2c6/0x3b0 [ 2.502762] ret_from_fork+0x36e/0x5a0 [ 2.502925] ret_from_fork_asm+0x1a/0x30 [ 2.503103]=20 [ 2.503177] The buggy address belongs to the object at ffff888005640680 [ 2.503177] which belongs to the cache kmalloc-96 of size 96 [ 2.503692] The buggy address is located 22 bytes to the right of [ 2.503692] allocated 72-byte region [ffff888005640680, ffff888005640= 6c8) [ 2.504227]=20 [ 2.504300] The buggy address belongs to the physical page: [ 2.504535] page: refcount:0 mapcount:0 mapping:0000000000000000 index= :0x0 pfn:0x5640 [ 2.504865] flags: 0x100000000000000(node=3D0|zone=3D1) [ 2.505076] page_type: f5(slab) [ 2.505221] raw: 0100000000000000 ffff888001041280 dead000000000122 00= 00000000000000 [ 2.505544] raw: 0000000000000000 0000000000200020 00000000f5000000 00= 00000000000000 [ 2.505867] page dumped because: kasan: bad access detected [ 2.506102]=20 [ 2.506176] Memory state around the buggy address: [ 2.506380] ffff888005640580: 00 00 00 00 00 00 00 00 00 fc fc fc fc = fc fc fc [ 2.506683] ffff888005640600: 00 00 00 00 00 00 00 00 00 fc fc fc fc = fc fc fc [ 2.506987] >ffff888005640680: 00 00 00 00 00 00 00 00 00 fc fc fc fc = fc fc fc [ 2.507291] ^ [ 2.507548] ffff888005640700: 00 00 00 00 00 00 00 00 00 fc fc fc fc = fc fc fc [ 2.507850] ffff888005640780: 00 00 00 00 00 00 00 00 00 fc fc fc fc = fc fc fc Whatever that read finds then bounds the ext->rt[] loop, so a peer that declares 255 rkeys reads much further. smc_llc_rmt_delete_rkey() has the same shape for llcv2->rkey[]. Bound both loops by the buffer they read from, and skip the extension altogether when there is no shared v2 receive buffer. The extension does arrive on the link, but smc_llc_enqueue() copies only sizeof(union smc_llc_msg) into the queue entry, so what that code read past the 44 inline bytes was heap and not peer data. Fixes: 27ef6a9981fe ("net/smc: support SMC-R V2 for rdma devices with max_r= ecv_sge equals to 1") Cc: stable@vger.kernel.org Signed-off-by: Yehyeong Lee Reviewed-by: Sidraya Jayagond --- v4 -> v5: corrected the reason given for skipping the extension. It does arrive on the link; what is not there is the copy in the queue entry. No functional change. Measured over rxe with KASAN and max_recv_sge forced to 1, five test cells (plain 1-rkey delete, delete declaring 255, plain ADD_LINK v2, ADD_LINK declaring 255, and an SMC-Rv1 link group). Without this patch four of the five report; with it none do. With kasan_multi_shot the unpatched kernel reports 491 times in a single ADD_LINK run, the patched one not at all. Changes since v5: none. net/smc/smc_llc.c | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/net/smc/smc_llc.c b/net/smc/smc_llc.c index 055a03eee5b5..748d65186f68 100644 --- a/net/smc/smc_llc.c +++ b/net/smc/smc_llc.c @@ -1000,13 +1000,21 @@ static void smc_llc_save_add_link_rkeys(struct smc_= link *link, struct smc_link *link_new, u8 *llc_msg) { + const u32 rt_off =3D offsetof(struct smc_llc_msg_add_link_v2_ext, rt); struct smc_llc_msg_add_link_v2_ext *ext; struct smc_link_group *lgr =3D link->lgr; int max, i; =20 + /* Without a shared v2 receive buffer the extension is not copied + * into the queue entry, so not even ext->num_rkeys is there. + */ + if (!smc_link_shared_v2_rxbuf(link)) + return; ext =3D (struct smc_llc_msg_add_link_v2_ext *)(llc_msg + SMC_WR_TX_SIZE); max =3D min_t(u8, ext->num_rkeys, SMC_LLC_RKEYS_PER_MSG_V2); + max =3D min_t(u32, max, (SMC_WR_BUF_V2_SIZE - SMC_WR_TX_SIZE - rt_off) / + sizeof(ext->rt[0])); down_write(&lgr->rmbs_lock); for (i =3D 0; i < max; i++) { smc_rtoken_set(lgr, link->link_idx, link_new->link_idx, @@ -1811,17 +1819,25 @@ static void smc_llc_rmt_delete_rkey(struct smc_link= _group *lgr) link =3D qentry->link; =20 if (lgr->smc_version =3D=3D SMC_V2) { + const u32 rkey_off =3D + offsetof(struct smc_llc_msg_delete_rkey_v2, rkey); struct smc_llc_msg_delete_rkey_v2 *llcv2; + u32 buf_len; =20 if (smc_link_shared_v2_rxbuf(link)) { memcpy(lgr->wr_rx_buf_v2, llc, sizeof(*llc)); llcv2 =3D (struct smc_llc_msg_delete_rkey_v2 *)lgr->wr_rx_buf_v2; + buf_len =3D SMC_WR_BUF_V2_SIZE; } else { llcv2 =3D (struct smc_llc_msg_delete_rkey_v2 *)llc; + buf_len =3D sizeof(qentry->msg); } llcv2->num_inval_rkeys =3D 0; =20 max =3D min_t(u8, llcv2->num_rkeys, SMC_LLC_RKEYS_PER_MSG_V2); + /* bound by the buffer llcv2 points at */ + max =3D min_t(u32, max, (buf_len - rkey_off) / + sizeof(llcv2->rkey[0])); for (i =3D 0; i < max; i++) { if (smc_rtoken_delete(link, llcv2->rkey[i])) llcv2->num_inval_rkeys++; --=20 2.43.0 From nobody Tue Sep 29 05:35:42 2026 Received: from mail-pl1-f175.google.com (mail-pl1-f175.google.com [209.85.214.175]) (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 CF26442C51D for ; Tue, 11 Aug 2026 23:20:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.175 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786490434; cv=none; b=I6oPN/dqtSAilNLbsp9TrMC2HdZBLscBJBaNl/vOSVRf2mqqR9ZbVFHBlAIem2xAlQOW33L1pPl2wwbKSKkFpia7Qu2rj9KSFr8huH9CnE+wc/nf9CswhA5xMlowSSDMzEcljZ9FUNUSFbLqvei/5NlaQAJAPQMrtgqLwg5N0Tw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786490434; c=relaxed/simple; bh=sAXUSDhd5C92E90UzlLJgvWzrxTdd/la48gzxdYlKUM=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=ho8jrm4aObpO1J85xwjGEb4R4frqJk2ow7iK9qx6x4dAUTo/ouJy5kBRuN5jBwcmbpiOfTTta6v2aLWtxgnZxqX9h/0ZWgOjZHASRzI/cUR7HS3lwdh0S3VSqwwrWd9q866REXB24BP46J6VRODcf5nja99PiEp7Y5Y+BPS7lIs= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=fail (p=none dis=none) header.from=isslab.korea.ac.kr; spf=none smtp.mailfrom=isslab.korea.ac.kr; dkim=pass (2048-bit key) header.d=isslab-korea-ac-kr.20251104.gappssmtp.com header.i=@isslab-korea-ac-kr.20251104.gappssmtp.com header.b=oAt9E14B; arc=none smtp.client-ip=209.85.214.175 Authentication-Results: smtp.subspace.kernel.org; dmarc=fail (p=none dis=none) header.from=isslab.korea.ac.kr Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=isslab.korea.ac.kr Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=isslab-korea-ac-kr.20251104.gappssmtp.com header.i=@isslab-korea-ac-kr.20251104.gappssmtp.com header.b="oAt9E14B" Received: by mail-pl1-f175.google.com with SMTP id d9443c01a7336-2cab973140bso8552085ad.3 for ; Tue, 11 Aug 2026 16:20:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isslab-korea-ac-kr.20251104.gappssmtp.com; s=20251104; t=1786490432; x=1787095232; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=1nlByblwJZP4nBWzVBd3o5LKRBdrzXBuUnjDk5jOhHI=; b=oAt9E14BhoQSaTwGEL6qB0Jmcx12o7ve4cbh9iqigLQVnjpRG2UTCZUWO6I4jUPK1q GZequSayDe3/ThRKluQLYI1esxjb0fXfNloOZzZj1dgELxVaA2mX5Gcq1RV9YTc2Pykm VTdfmzbyV1yYUzRNQe7GA0FxaEQMHppSjh+QsUeouXASmID0fxk8wCIymRc6wCiHqap7 fb+6y/MgLcQWhGIibKrtOOoa1/S1RzLVQKfdjQBm7+kz16BxZg7MbSip3g2Ge0To5yj0 Td4mZQBEM/NcepNZvFfGD2g542yZBFaAoU1agMKnOyAtVTtDQz82IjkVAmSU/dj1cf1d Sd/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786490432; x=1787095232; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=1nlByblwJZP4nBWzVBd3o5LKRBdrzXBuUnjDk5jOhHI=; b=ZFPzMgSiOUgdP1y7XeNl5x5/1O1sEn+USPqma3bknThfF1+7CuclyKvjqsLXLIX9xD sFVQTryt2Hp4XxsPpyDxT8mmazcubeQnoJF8GMuGjAw2BKYnGnu90Va7WTw+eiovzOgx bGjl9Ki7u8Ul8X/ETHtPj+fAc+pkZqBwHUpiGC6cddffyPtv45SqPzncrwrOAdjNQ5q1 Vhvc/GVWGTfHda8gQf4NaEwgDHCN21XEYJZEWhp6Y6YdsrUxOVwkli2MmsuuWTiC+n7E NfOwyJzJLHMiS+L0ycNwm/V3yzkMIO4ZVSxvJonvM2pcCrgukasluTDXQ9/KHVRUoFIj 0YrA== X-Forwarded-Encrypted: i=1; AHgh+RrxAlFQ4mLqpoQoKwmbc8ErSpqIpxpQZWU3WtdlYnIh/2wPliznjL4C5KWc1uwK/XPFljLeK85dYnpFSpk=@vger.kernel.org X-Gm-Message-State: AOJu0Yzeu6rryVa/6q0ClV5t6rVQByfKnu0I5GxFt1awC2Jio9NowCKb JFPexbJKf7WBWjDVA+6UXma+CoujMlh3gOMbhmtXyKcLzHRvmMot9xc882OxFvKT1fU= X-Gm-Gg: AR+sD10WT0odu/8LqQ+eieZExD+EZzDj7xga2L/0SBO+spwtySY3rzxBUy2Vd9+H3MF k/NCK0EYgQtj8t0BfmV6qcmb3RrtEF7zw3VbaVzfhqK8NvANbtUcpWLUs4McOYQyw9yMT/GDNOl 1YzrZN7WGKdTxPriFQAHGcfMDHYuUzip8npROdNguoOZPA68CvUjf0FGNFADapQMGFMBzPdnJtT friNjqqIjsVGd6kLOWpofknVRcWKU7B6OCw24H7JuoDurqWTHRGQvLZiAAJCjb/d+4shKyK1Xoz XlAuS60kGWcZVV8iK6hXVmHm4YI4hBlIvf54TsPM5IN2PvpWji9HHjhuF+cAH+/Ig3az21EIGs/ ZZ11ewfeaaxm9ZnOSApa/To1YZX0PZ5y0mFrPRGX7IGUOFwIkCv2r+6WVQeErHOX5whu2n2vPYv WjAYOuuJ3WjKzLWQsNm6yAW00py9YXLRYCvO4SUbfhfqUqblYFv0xE3aw3S18M+FLHqdLFkGWoP swd2LKc78U= X-Received: by 2002:a05:6a20:158e:b0:3c3:a3f4:5485 with SMTP id adf61e73a8af0-3cc3f52989amr478455637.6.1786490432010; Tue, 11 Aug 2026 16:20:32 -0700 (PDT) Received: from yhlee-960QFG.Davolink ([2406:5900:1044:110c:365f:6c09:b402:1986]) by smtp.gmail.com with ESMTPSA id 41be03b00d2f7-cbedbac8842sm1177810a12.30.2026.08.11.16.20.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 11 Aug 2026 16:20:31 -0700 (PDT) From: Yehyeong Lee To: alibuda@linux.alibaba.com, dust.li@linux.alibaba.com, sidraya@linux.ibm.com, wenjia@linux.ibm.com, kuba@kernel.org, davem@davemloft.net, edumazet@google.com, pabeni@redhat.com Cc: leitao@debian.org, horms@kernel.org, mjambigi@linux.ibm.com, tonylu@linux.alibaba.com, guwen@linux.alibaba.com, guangguan.wang@linux.alibaba.com, kees@kernel.org, gustavoars@kernel.org, netdev@vger.kernel.org, linux-rdma@vger.kernel.org, linux-s390@vger.kernel.org, linux-hardening@vger.kernel.org, linux-kernel@vger.kernel.org, Yehyeong Lee , stable@vger.kernel.org Subject: [PATCH net v6 3/3] net/smc: carry oversized SMC-Rv2 LLC messages in the queue entry Date: Wed, 12 Aug 2026 08:19:02 +0900 Message-ID: <20260811231902.47089-4-yhlee@isslab.korea.ac.kr> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260811231902.47089-1-yhlee@isslab.korea.ac.kr> References: <20260811231902.47089-1-yhlee@isslab.korea.ac.kr> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" smc_llc_rmt_delete_rkey() and smc_llc_save_add_link_rkeys() read the part of a v2 message that does not fit into the 44-byte union smc_llc_msg, and both bound themselves by the size of the buffer it landed in, not by what arrived. On a link with a shared v2 receive buffer a 44-byte DELETE_RKEY_V2 declaring 255 rkeys reaches rkey[9..254] in whatever an earlier message left in lgr->wr_rx_buf_v2, and passes each of them to smc_rtoken_delete(). One of those 255 matched a registered rtoken and deleted it. An ADD_LINK on such a link installs up to 255 rtokens from the same bytes. Copy the tail into the queue entry, so its length is the length of the message that arrived, and declare the rkeys that fit inline as a member of the union instead of reaching them through a cast. The same DELETE_RKEY_V2 now processes the 9 rkeys it carries. The copy is limited to the longest tail the two functions can read, so the peer does not pick the size of the entry. The bound the previous patch placed on links without a shared v2 receive buffer is no longer needed. Fixes: 27ef6a9981fe ("net/smc: support SMC-R V2 for rdma devices with max_r= ecv_sge equals to 1") Cc: stable@vger.kernel.org Suggested-by: D. Wythe Signed-off-by: Yehyeong Lee Reviewed-by: Sidraya Jayagond --- Changes since v5: added the Fixes: and Cc: stable tags; asserted that the t= wo DELETE_RKEY_V2 layouts agree on offsetof(rkey); limited the copied tail to what the two readers can use; corrected the comment in smc_wr_init_sge(). Measured over rxe with KASAN: a DELETE_RKEY_V2 carrying 12 rkeys over a link with a shared v2 receive buffer round-trips all 12 values, the last three coming from the copied tail; 8, 9 and 10 rkeys and a 44-byte message declar= ing 10 give 8, 9, 10 and 9 processed rkeys respectively. kmemleak reports noth= ing over the link-addition path, and does report the queue entry when the free added by patch 1 is removed again. Five runs per cell with and without the new limit: a 44-byte DELETE_RKEY_V2 declaring 255 rkeys reports 9 processed on a link with and without a shared v2 receive buffer, an ADD_LINK v2 extension installs the 6 rtokens the peer sent, and no KASAN report appears. The only message the limit changes in that lab is a REQ_ADD_LINK, which copied 16 bytes that have no reader and now copies none. On the unpatched kernel the same DELETE_RKEY_V2 reports 254 and 255, and the ADD_LINK installs 255 rtokens per call. net/smc/smc_llc.c | 125 ++++++++++++++++++++++++++++++++-------------- net/smc/smc_wr.c | 6 +-- 2 files changed, 91 insertions(+), 40 deletions(-) diff --git a/net/smc/smc_llc.c b/net/smc/smc_llc.c index 748d65186f68..393aa0af18d1 100644 --- a/net/smc/smc_llc.c +++ b/net/smc/smc_llc.c @@ -157,6 +157,7 @@ struct smc_llc_msg_confirm_rkey { /* type 0x06 */ }; =20 #define SMC_LLC_DEL_RKEY_MAX 8 +#define SMC_LLC_DEL_RKEY_V2_INLINE 9 #define SMC_LLC_FLAG_RKEY_RETRY 0x10 #define SMC_LLC_FLAG_RKEY_NEG 0x20 =20 @@ -177,6 +178,15 @@ struct smc_llc_msg_delete_rkey_v2 { /* type 0x29 */ __be32 rkey[]; }; =20 +/* the leading rkeys of a DELETE_RKEY_V2 fit into union smc_llc_msg */ +struct smc_llc_msg_delete_rkey_v2_inline { /* type 0x29 */ + struct smc_llc_hdr hd; + u8 num_rkeys; + u8 num_inval_rkeys; + u8 reserved[2]; + __be32 rkey[SMC_LLC_DEL_RKEY_V2_INLINE]; +}; + union smc_llc_msg { struct smc_llc_msg_confirm_link confirm_link; struct smc_llc_msg_add_link add_link; @@ -186,6 +196,7 @@ union smc_llc_msg { =20 struct smc_llc_msg_confirm_rkey confirm_rkey; struct smc_llc_msg_delete_rkey delete_rkey; + struct smc_llc_msg_delete_rkey_v2_inline delete_rkey_v2; =20 struct smc_llc_msg_test_link test_link; struct { @@ -194,15 +205,25 @@ union smc_llc_msg { } raw; }; =20 +static_assert(SMC_LLC_DEL_RKEY_V2_INLINE =3D=3D + (sizeof(union smc_llc_msg) - + offsetof(struct smc_llc_msg_delete_rkey_v2, rkey)) / + sizeof(__be32)); +static_assert(offsetof(struct smc_llc_msg_delete_rkey_v2_inline, rkey) =3D= =3D + offsetof(struct smc_llc_msg_delete_rkey_v2, rkey)); + #define SMC_LLC_FLAG_RESP 0x80 =20 struct smc_llc_qentry { struct list_head list; struct smc_link *link; + u16 body_len; union smc_llc_msg msg; + u8 body[] __counted_by(body_len); }; =20 -static void smc_llc_enqueue(struct smc_link *link, union smc_llc_msg *llc); +static void smc_llc_enqueue(struct smc_link *link, union smc_llc_msg *llc, + u32 byte_len); =20 struct smc_llc_qentry *smc_llc_flow_qentry_clr(struct smc_llc_flow *flow) { @@ -998,22 +1019,19 @@ static int smc_llc_cli_conf_link(struct smc_link *li= nk, =20 static void smc_llc_save_add_link_rkeys(struct smc_link *link, struct smc_link *link_new, - u8 *llc_msg) + struct smc_llc_qentry *qentry) { const u32 rt_off =3D offsetof(struct smc_llc_msg_add_link_v2_ext, rt); struct smc_llc_msg_add_link_v2_ext *ext; struct smc_link_group *lgr =3D link->lgr; int max, i; =20 - /* Without a shared v2 receive buffer the extension is not copied - * into the queue entry, so not even ext->num_rkeys is there. - */ - if (!smc_link_shared_v2_rxbuf(link)) + /* the rkey count itself is only there if enough bytes arrived */ + if (qentry->body_len < rt_off) return; - ext =3D (struct smc_llc_msg_add_link_v2_ext *)(llc_msg + - SMC_WR_TX_SIZE); + ext =3D (struct smc_llc_msg_add_link_v2_ext *)qentry->body; max =3D min_t(u8, ext->num_rkeys, SMC_LLC_RKEYS_PER_MSG_V2); - max =3D min_t(u32, max, (SMC_WR_BUF_V2_SIZE - SMC_WR_TX_SIZE - rt_off) / + max =3D min_t(u32, max, (qentry->body_len - rt_off) / sizeof(ext->rt[0])); down_write(&lgr->rmbs_lock); for (i =3D 0; i < max; i++) { @@ -1107,9 +1125,7 @@ int smc_llc_cli_add_link(struct smc_link *link, struc= t smc_llc_qentry *qentry) if (rc) goto out_clear_lnk; if (lgr->smc_version =3D=3D SMC_V2) { - u8 *llc_msg =3D smc_link_shared_v2_rxbuf(link) ? - (u8 *)lgr->wr_rx_buf_v2 : (u8 *)llc; - smc_llc_save_add_link_rkeys(link, lnk_new, llc_msg); + smc_llc_save_add_link_rkeys(link, lnk_new, qentry); } else { rc =3D smc_llc_cli_rkey_exchange(link, lnk_new); if (rc) { @@ -1510,9 +1526,7 @@ int smc_llc_srv_add_link(struct smc_link *link, if (rc) goto out_err; if (lgr->smc_version =3D=3D SMC_V2) { - u8 *llc_msg =3D smc_link_shared_v2_rxbuf(link) ? - (u8 *)lgr->wr_rx_buf_v2 : (u8 *)add_llc; - smc_llc_save_add_link_rkeys(link, link_new, llc_msg); + smc_llc_save_add_link_rkeys(link, link_new, qentry); } else { rc =3D smc_llc_srv_rkey_exchange(link, link_new); if (rc) @@ -1561,7 +1575,8 @@ void smc_llc_add_link_local(struct smc_link *link) add_llc.hd.common.llc_type =3D SMC_LLC_ADD_LINK; smc_llc_init_msg_hdr(&add_llc.hd, link->lgr, sizeof(add_llc)); /* no dev and port needed */ - smc_llc_enqueue(link, (union smc_llc_msg *)&add_llc); + smc_llc_enqueue(link, (union smc_llc_msg *)&add_llc, + sizeof(union smc_llc_msg)); } =20 /* worker to process an add link message */ @@ -1597,7 +1612,8 @@ void smc_llc_srv_delete_link_local(struct smc_link *l= ink, u8 del_link_id) del_llc.link_num =3D del_link_id; del_llc.reason =3D htonl(SMC_LLC_DEL_LOST_PATH); del_llc.hd.flags |=3D SMC_LLC_FLAG_DEL_LINK_ORDERLY; - smc_llc_enqueue(link, (union smc_llc_msg *)&del_llc); + smc_llc_enqueue(link, (union smc_llc_msg *)&del_llc, + sizeof(union smc_llc_msg)); } =20 static void smc_llc_process_cli_delete_link(struct smc_link_group *lgr) @@ -1819,27 +1835,28 @@ static void smc_llc_rmt_delete_rkey(struct smc_link= _group *lgr) link =3D qentry->link; =20 if (lgr->smc_version =3D=3D SMC_V2) { - const u32 rkey_off =3D - offsetof(struct smc_llc_msg_delete_rkey_v2, rkey); - struct smc_llc_msg_delete_rkey_v2 *llcv2; - u32 buf_len; - - if (smc_link_shared_v2_rxbuf(link)) { - memcpy(lgr->wr_rx_buf_v2, llc, sizeof(*llc)); - llcv2 =3D (struct smc_llc_msg_delete_rkey_v2 *)lgr->wr_rx_buf_v2; - buf_len =3D SMC_WR_BUF_V2_SIZE; - } else { - llcv2 =3D (struct smc_llc_msg_delete_rkey_v2 *)llc; - buf_len =3D sizeof(qentry->msg); - } + struct smc_llc_msg_delete_rkey_v2_inline *llcv2; + + /* The leading SMC_LLC_DEL_RKEY_V2_INLINE rkeys are declared in + * the message itself, any further ones were received into + * qentry->body. + */ + llcv2 =3D &qentry->msg.delete_rkey_v2; llcv2->num_inval_rkeys =3D 0; =20 max =3D min_t(u8, llcv2->num_rkeys, SMC_LLC_RKEYS_PER_MSG_V2); - /* bound by the buffer llcv2 points at */ - max =3D min_t(u32, max, (buf_len - rkey_off) / - sizeof(llcv2->rkey[0])); + max =3D min_t(u32, max, SMC_LLC_DEL_RKEY_V2_INLINE + + qentry->body_len / sizeof(__be32)); for (i =3D 0; i < max; i++) { - if (smc_rtoken_delete(link, llcv2->rkey[i])) + __be32 rkey; + + if (i < SMC_LLC_DEL_RKEY_V2_INLINE) + rkey =3D llcv2->rkey[i]; + else + memcpy(&rkey, qentry->body + + (i - SMC_LLC_DEL_RKEY_V2_INLINE) * + sizeof(rkey), sizeof(rkey)); + if (smc_rtoken_delete(link, rkey)) llcv2->num_inval_rkeys++; } memset(&llc->rkey[0], 0, sizeof(llc->rkey)); @@ -2080,18 +2097,52 @@ static void smc_llc_rx_response(struct smc_link *li= nk, wake_up(&link->lgr->llc_msg_waiter); } =20 -static void smc_llc_enqueue(struct smc_link *link, union smc_llc_msg *llc) +/* the longest tail either reader of qentry->body can use */ +static u32 smc_llc_max_body_len(union smc_llc_msg *llc) +{ + switch (llc->raw.hdr.common.llc_type) { + case SMC_LLC_ADD_LINK: + return offsetof(struct smc_llc_msg_add_link_v2_ext, rt) + + SMC_LLC_RKEYS_PER_MSG_V2 * + sizeof(struct smc_llc_msg_add_link_cont_rt); + case SMC_LLC_DELETE_RKEY: + return (SMC_LLC_RKEYS_PER_MSG_V2 - + SMC_LLC_DEL_RKEY_V2_INLINE) * sizeof(__be32); + default: + return 0; + } +} + +static void smc_llc_enqueue(struct smc_link *link, union smc_llc_msg *llc, + u32 byte_len) { struct smc_link_group *lgr =3D link->lgr; struct smc_llc_qentry *qentry; unsigned long flags; + u16 body_len =3D 0; + + /* V2 messages can be longer than the inline union smc_llc_msg. Carry + * the remainder in the qentry itself, so that its lifetime and its + * length match the message the peer actually sent. + */ + if (lgr->smc_version =3D=3D SMC_V2 && byte_len > SMC_WR_TX_SIZE) + body_len =3D min_t(u32, byte_len, SMC_WR_BUF_V2_SIZE) - + SMC_WR_TX_SIZE; + body_len =3D min_t(u32, body_len, smc_llc_max_body_len(llc)); =20 - qentry =3D kmalloc_obj(*qentry, GFP_ATOMIC); + qentry =3D kmalloc_flex(*qentry, body, body_len, GFP_ATOMIC); if (!qentry) return; + qentry->body_len =3D body_len; qentry->link =3D link; INIT_LIST_HEAD(&qentry->list); memcpy(&qentry->msg, llc, sizeof(union smc_llc_msg)); + if (body_len) { + u8 *src =3D smc_link_shared_v2_rxbuf(link) ? + (u8 *)lgr->wr_rx_buf_v2 : (u8 *)llc; + + memcpy(qentry->body, src + SMC_WR_TX_SIZE, body_len); + } =20 /* process responses immediately */ if ((llc->raw.hdr.flags & SMC_LLC_FLAG_RESP) && @@ -2123,7 +2174,7 @@ static void smc_llc_rx_handler(struct ib_wc *wc, void= *buf) return; /* invalid message */ } =20 - smc_llc_enqueue(link, llc); + smc_llc_enqueue(link, llc, wc->byte_len); } =20 /***************************** worker, utils *****************************= ****/ diff --git a/net/smc/smc_wr.c b/net/smc/smc_wr.c index 59c92b46945c..97ba46893b17 100644 --- a/net/smc/smc_wr.c +++ b/net/smc/smc_wr.c @@ -602,9 +602,9 @@ static void smc_wr_init_sge(struct smc_link *lnk) =20 /* With SMC-Rv2 there can be messages larger than SMC_WR_TX_SIZE. * Each ib_recv_wr gets 2 sges, the second one is a spillover buffer - * and the same buffer for all sges. When a larger message arrived then - * the content of the first small sge is copied to the beginning of - * the larger spillover buffer, allowing easy data mapping. + * and the same buffer for all sges. The spillover sge starts at + * SMC_WR_TX_SIZE, so the leading bytes of that buffer are never + * written. */ for (i =3D 0; i < lnk->wr_rx_cnt; i++) { int x =3D i * lnk->wr_rx_sge_cnt; --=20 2.43.0