All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH 5.10] net/smc: reject CHID-0 ACCEPT that matches an empty ism_dev slot
@ 2026-08-20  6:44 Andrey Troshin
  2026-08-21  6:44 ` sashiko-bot
  0 siblings, 1 reply; 2+ messages in thread
From: Andrey Troshin @ 2026-08-20  6:44 UTC (permalink / raw)
  To: stable, Greg Kroah-Hartman
  Cc: Andrey Troshin, Sasha Levin, Karsten Graul, David S. Miller,
	Jakub Kicinski, linux-s390, netdev, linux-kernel, lvc-project

From: Xiang Mei <xmei5@asu.edu>

[ Upstream commit 277740023def559a4a2ddc3e8e784ee37a0f16a9 ]

On the SMC-D client, slot 0 of ini->ism_dev[]/ini->ism_chid[] is
reserved for an SMC-Dv1 device. smc_find_ism_v2_device_clnt()
populates V2 entries starting at index 1, so when no V1 device is
selected slot 0 is left in its kzalloc()'ed state with ism_dev[0] ==
NULL and ism_chid[0] == 0.

smc_v2_determine_accepted_chid() then matches the peer's CHID against
the array starting from index 0 using the CHID alone. A malicious
peer replying to a SMC-Dv2-only proposal with d1.chid == 0 matches
the empty slot, ini->ism_selected becomes 0, and the subsequent
ism_dev[0]->lgr_lock dereference in smc_conn_create() faults at
offsetof(struct smcd_dev, lgr_lock) == 0x68:

  BUG: KASAN: null-ptr-deref in _raw_spin_lock_bh+0x79/0xe0
  Write of size 4 at addr 0000000000000068 by task exploit/144
  Call Trace:
   _raw_spin_lock_bh
   smc_conn_create (net/smc/smc_core.c:1997)
   __smc_connect (net/smc/af_smc.c:1447)
   smc_connect (net/smc/af_smc.c:1720)
   __sys_connect
   __x64_sys_connect
   do_syscall_64

Require ism_dev[i] to be non-NULL before accepting a CHID match.

Fixes: a7c9c5f4af7f ("net/smc: CLC accept / confirm V2")
Reported-by: Weiming Shi <bestswngs@gmail.com>
Assisted-by: Claude:claude-opus-4-7
Signed-off-by: Xiang Mei <xmei5@asu.edu>
Link: https://patch.msgid.link/20260511062138.2839584-1-xmei5@asu.edu
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: Andrey Troshin <drtrosh@yandex-team.ru>
---
Backport fix for CVE-2026-64048
Link: https://nvd.nist.gov/vuln/detail/CVE-2026-64048
---
 net/smc/af_smc.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/net/smc/af_smc.c b/net/smc/af_smc.c
index 8e1e38bc0df4..e9dabe758a31 100644
--- a/net/smc/af_smc.c
+++ b/net/smc/af_smc.c
@@ -863,7 +863,8 @@ smc_v2_determine_accepted_chid(struct smc_clc_msg_accept_confirm_v2 *aclc,
 	int i;
 
 	for (i = 0; i < ini->ism_offered_cnt + 1; i++) {
-		if (ini->ism_chid[i] == ntohs(aclc->chid)) {
+		if (ini->ism_dev[i] &&
+			ini->ism_chid[i] == ntohs(aclc->chid)) {
 			ini->ism_selected = i;
 			return 0;
 		}
-- 
2.34.1


^ permalink raw reply related	[flat|nested] 2+ messages in thread

* Re: [PATCH 5.10] net/smc: reject CHID-0 ACCEPT that matches an empty ism_dev slot
  2026-08-20  6:44 [PATCH 5.10] net/smc: reject CHID-0 ACCEPT that matches an empty ism_dev slot Andrey Troshin
@ 2026-08-21  6:44 ` sashiko-bot
  0 siblings, 0 replies; 2+ messages in thread
From: sashiko-bot @ 2026-08-21  6:44 UTC (permalink / raw)
  To: Andrey Troshin
  Cc: Heiko Carstens, Christian Borntraeger, Vasily Gorbik,
	Alexander Gordeev, linux-s390

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

Pre-existing issues:
- [Critical] Missing bounds checks on offsets and array counts (e.g., `ism_gid_cnt`) in SMC CLC proposal message parsing allows out-of-bounds heap reads and unbounded array writes in `smc_check_ism_v2_match`, leading to heap buffer overflow.
- [High] Missing reference counting for ISM (`smcd_dev`) and RoCE (`smc_ib_device`) devices in `smc_init_info` across blocking network calls leads to Use-After-Free vulnerabilities.
--

--- Patch [1]: [PATCH 5.10] net/smc: reject CHID-0 ACCEPT that matches an empty ism_dev slot ---
commit 970c1e9eb76354e20020ef1c7e5ec94d92578af6
Author: Xiang Mei <xmei5@asu.edu>

net/smc: reject CHID-0 ACCEPT that matches an empty ism_dev slot

This commit fixes a null-pointer dereference in the SMC-D client. It prevents
a malicious peer from matching an empty ism_dev slot by replying with a CHID 
of 0, which previously caused a crash when accessing the link group lock.

Link: https://patch.msgid.link/20260511062138.2839584-1-xmei5@asu.edu
Link: https://nvd.nist.gov/vuln/detail/CVE-2026-64048

> diff --git a/net/smc/af_smc.c b/net/smc/af_smc.c
> index 5dd4faaf7d6e5..72fa6d40916b8 100644
> --- a/net/smc/af_smc.c
> +++ b/net/smc/af_smc.c
> @@ -831,7 +831,8 @@ smc_v2_determine_accepted_chid(struct smc_clc_msg_accept_confirm_v2 *aclc,
>  	int i;
>  
>  	for (i = 0; i < ini->ism_offered_cnt + 1; i++) {
> -		if (ini->ism_chid[i] == ntohs(aclc->chid)) {
> +		if (ini->ism_dev[i] &&
> +			ini->ism_chid[i] == ntohs(aclc->chid)) {

[Severity: Critical]
This isn't a bug introduced by this patch, but is there an out-of-bounds read 
and write when parsing SMC CLC proposal messages?

When reading the packet in net/smc/smc_clc.c:smc_clc_wait_msg():

    recvlen = datlen > SMC_CLC_RECV_BUF_LEN ? SMC_CLC_RECV_BUF_LEN : datlen;
    iov_iter_kvec(&msg.msg_iter, READ, &vec, 1, recvlen);

The data length is truncated to fit the fixed-size buffer. However, when 
extracting the v2 extension in net/smc/smc_clc.h:smc_get_clc_v2_ext():

    return (struct smc_clc_v2_extension *)
           ((u8 *)prop_smcd +
           offsetof(struct smc_clc_msg_smcd, v2_ext_offset) +
           sizeof(prop_smcd->v2_ext_offset) +
           ntohs(prop_smcd->v2_ext_offset));

Does this calculate an out-of-bounds pointer because the unvalidated 
v2_ext_offset is not checked against the truncated buffer boundary?

This appears to lead to an out-of-bounds read when checking array counts like 
ism_gid_cnt in net/smc/smc_clc.c:smc_clc_msg_prop_valid().

Furthermore, in net/smc/af_smc.c:smc_find_ism_v2_device_serv(), the loop 
iterates up to this unvalidated ism_gid_cnt:

    for (i = 1; i <= smc_v2_ext->hdr.ism_gid_cnt; i++) {
        smc_check_ism_v2_match(ini,
                               ntohs(smcd_v2_ext->gidchid[i - 1].chid),
                               ntohll(smcd_v2_ext->gidchid[i - 1].gid),
                               &matches);
    }

Inside net/smc/af_smc.c:smc_check_ism_v2_match():

    ini->ism_peer_gid[*matches] = proposed_gid;
    ini->ism_dev[*matches] = smcd;
    (*matches)++;

Can this overflow the fixed-size ini->ism_peer_gid and ini->ism_dev arrays 
if the remote side controls ism_gid_cnt or repeatedly matches the same device, 
since *matches is not bounds-checked against SMC_MAX_ISM_DEVS?

[Severity: High]
This is a pre-existing issue, but does this code lack reference counting for 
ISM devices across blocking network calls?

In net/smc/af_smc.c:smc_find_ism_v2_device_clnt(), raw device pointers are 
collected in the ini struct without a reference count:

    ini->ism_dev[i] = smcd;
    ini->ism_chid[i] = chid;

The system then goes to sleep waiting for network data:
net/smc/af_smc.c:__smc_connect() -> smc_connect_clc()

When it resumes, the device pointer is dereferenced in 
net/smc/smc_core.c:smc_conn_create():

    smcd = ini->ism_dev[ini->ism_selected];
    lgr_list = &smcd->lgr_list;
    lgr_lock = &smcd->lgr_lock;

If a hardware hotplug event unregisters the device while blocked in 
smc_connect_clc(), could this lead to a use-after-free when smc_conn_create() 
accesses the freed pointer?

>  			ini->ism_selected = i;
>  			return 0;
>  		}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260820064415.2061-1-drtrosh@yandex-team.ru?part=1

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2026-08-21  6:44 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-08-20  6:44 [PATCH 5.10] net/smc: reject CHID-0 ACCEPT that matches an empty ism_dev slot Andrey Troshin
2026-08-21  6:44 ` sashiko-bot

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.