[PATCH 5.15] net/smc: reject CHID-0 ACCEPT that matches an empty ism_dev slot

[PATCH 5.15] net/smc: reject CHID-0 ACCEPT that matches an empty ism_dev slot

[Andrey Troshin]

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 6b60a5dd240d..c283f0272a77 100644
--- a/net/smc/af_smc.c
+++ b/net/smc/af_smc.c
@@ -1107,7 +1107,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

Re: [PATCH 5.15] net/smc: reject CHID-0 ACCEPT that matches an empty ism_dev slot

[sashiko-bot]

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

Pre-existing issues:
- [High] Unvalidated offsets and lengths in SMC CLC proposals allow arbitrary out-of-bounds heap memory reads.
- [High] Use-after-free of `smcd_dev` and `smc_ib_device` across a sleep due to missing reference tracking.
- [High] Unauthenticated NULL pointer dereference when processing SMC-D CLC proposals with missing v2 extensions.
- [High] Remote heap buffer overflow in `ini->ism_dev` array during ISM device matching.
--

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

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

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.

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 78b663dbfa1f9..dd2a338eb6efe 100644
> --- a/net/smc/af_smc.c
> +++ b/net/smc/af_smc.c
> @@ -869,7 +869,8 @@ smc_v2_determine_accepted_chid(struct smc_clc_msg_accept_confirm_v2 *aclc,
[ ... ]
> -		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;
>  		}

> net/smc/smc_clc.c:smc_clc_msg_prop_valid()
> (hdr->typev2 != SMC_TYPE_N ?
> 	sizeof(*v2_ext) +
> 	v2_ext->hdr.eid_cnt * SMC_MAX_EID_LEN : 0) +

[Severity: High]
This isn't a bug introduced by this patch, but does this pointer calculation
validate that the offset is within the bounds of the allocated buffer?

It appears that in smc_get_clc_v2_ext(), the pointer is constructed using
an offset without bounds checking:

> 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));

Could this read beyond the heap allocation if the offset is too large?

[Severity: High]
This is a pre-existing issue, but if v2_ext_offset is explicitly 0,
smc_get_clc_v2_ext() returns NULL. Does this code safely handle a NULL
return for v2_ext? It looks like v2_ext->hdr.eid_cnt is unconditionally
dereferenced when hdr->typev2 indicates an SMC-D proposal.

> net/smc/af_smc.c:smc_find_ism_v2_device_clnt()
> ini->ism_dev[i] = smcd;

[Severity: High]
This isn't a bug introduced by this patch, but is it possible for the device
to be unregistered and freed during a sleep in smc_clc_wait_msg()?

The device pointer is stored without taking a reference count to pin its
lifetime. Later, the potentially freed device pointer is dereferenced after
waking up:

> net/smc/smc_core.c:smc_conn_create()
> lgr_list = ini->is_smcd ? &ini->ism_dev[ini->ism_selected]->lgr_list :
>                           &smc_lgr_list.list;

Would acquiring a reference count prevent a dangling pointer here?

> net/smc/af_smc.c:smc_find_ism_v2_device_serv()
> 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);
> }

[Severity: High]
This is a pre-existing issue, but is there a bounds check preventing matches
from exceeding the size of the ini->ism_dev array?

The loop executes based on ism_gid_cnt, and each unique match increments
matches and stores the device pointer:

> net/smc/af_smc.c:smc_check_ism_v2_match()
> ini->ism_peer_gid[*matches] = proposed_gid;
> ini->ism_dev[*matches] = smcd;
> (*matches)++;

Could this write past the end of the array if there are many ISM devices?

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