* [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.