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

[Dust Li <dust.li@linux.alibaba.com>]

On 2026-05-10 23:21:38, Xiang Mei wrote:
>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>
>---
> 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 185dbed7de5d..12ea3b6dbc64 100644
>--- a/net/smc/af_smc.c
>+++ b/net/smc/af_smc.c
>@@ -1400,7 +1400,8 @@ smc_v2_determine_accepted_chid(struct smc_clc_msg_accept_confirm *aclc,
> 	int i;
> 
> 	for (i = 0; i < ini->ism_offered_cnt + 1; i++) {
>-		if (ini->ism_chid[i] == ntohs(aclc->d1.chid)) {
>+		if (ini->ism_dev[i] &&
>+		    ini->ism_chid[i] == ntohs(aclc->d1.chid)) {

I agree this can solve the bug you rised, but I also agree with
shashiko's comments here, we should have a better solution solving
this null-ptr-deref and use-after-free.

  Does this check leave us vulnerable to a use-after-free if the device
  is removed during the CLC handshake?
  smc_find_ism_v2_device_clnt() populates ini->ism_dev[i] with pointers to
  struct smcd_dev while holding the smcd_dev_list.mutex. However, it doesn't
  appear that struct smcd_dev has a reference counting mechanism.
  The client then drops the mutex and calls __smc_connect() ->
  smc_connect_clc(), which sleeps waiting for an ACCEPT message from the
  network peer.
  During this unbounded blocking wait, can the underlying ISM device be
  unregistered (e.g., via hardware unplug)?
  If smcd_unregister_dev() runs, it removes the device from the list and
  frees the memory using kfree(). It seems smc_smcd_terminate_all() only
  waits for fully established Link Groups, not for in-progress connection
  attempts.
  When the server accept message eventually arrives, ini->ism_dev[i] will
  still hold the dangling non-NULL pointer. This check evaluates to true,
  and the code will assign ini->ism_selected = i.
  Could this lead to smc_conn_create() actively dereferencing freed memory
  via &ini->ism_dev[ini->ism_selected]->lgr_lock?

Best regards,
Dust


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