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

[sashiko-bot@kernel.org]

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