[PATCH 5.10] net/smc: fix potential panic dues to unprotected smc_llc_srv_add_link()

[PATCH 5.10] net/smc: fix potential panic dues to unprotected smc_llc_srv_add_link()

[Denis Arefev]

From: "D. Wythe" <alibuda@linux.alibaba.com>

commit e40b801b3603a8f90b46acbacdea3505c27f01c0 upstream.

There is a certain chance to trigger the following panic:

PID: 5900   TASK: ffff88c1c8af4100  CPU: 1   COMMAND: "kworker/1:48"
 #0 [ffff9456c1cc79a0] machine_kexec at ffffffff870665b7
 #1 [ffff9456c1cc79f0] __crash_kexec at ffffffff871b4c7a
 #2 [ffff9456c1cc7ab0] crash_kexec at ffffffff871b5b60
 #3 [ffff9456c1cc7ac0] oops_end at ffffffff87026ce7
 #4 [ffff9456c1cc7ae0] page_fault_oops at ffffffff87075715
 #5 [ffff9456c1cc7b58] exc_page_fault at ffffffff87ad0654
 #6 [ffff9456c1cc7b80] asm_exc_page_fault at ffffffff87c00b62
    [exception RIP: ib_alloc_mr+19]
    RIP: ffffffffc0c9cce3  RSP: ffff9456c1cc7c38  RFLAGS: 00010202
    RAX: 0000000000000000  RBX: 0000000000000002  RCX: 0000000000000004
    RDX: 0000000000000010  RSI: 0000000000000000  RDI: 0000000000000000
    RBP: ffff88c1ea281d00   R8: 000000020a34ffff   R9: ffff88c1350bbb20
    R10: 0000000000000000  R11: 0000000000000001  R12: 0000000000000000
    R13: 0000000000000010  R14: ffff88c1ab040a50  R15: ffff88c1ea281d00
    ORIG_RAX: ffffffffffffffff  CS: 0010  SS: 0018
 #7 [ffff9456c1cc7c60] smc_ib_get_memory_region at ffffffffc0aff6df [smc]
 #8 [ffff9456c1cc7c88] smcr_buf_map_link at ffffffffc0b0278c [smc]
 #9 [ffff9456c1cc7ce0] __smc_buf_create at ffffffffc0b03586 [smc]

The reason here is that when the server tries to create a second link,
smc_llc_srv_add_link() has no protection and may add a new link to
link group. This breaks the security environment protected by
llc_conf_mutex.

Fixes: 2d2209f20189 ("net/smc: first part of add link processing as SMC server")
Signed-off-by: D. Wythe <alibuda@linux.alibaba.com>
Reviewed-by: Larysa Zaremba <larysa.zaremba@intel.com>
Reviewed-by: Wenjia Zhang <wenjia@linux.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
[Denis Arefev: adapted for 5.10: smc_llc_srv_add_link() has no 
req_qentry argument here, as SMC-Rv2 REQ_ADD_LINK support is
not present in 5.10]
Signed-off-by: Denis Arefev <arefev@swemel.ru>
---
Backport fix for CVE-2023-54237
Link: https://nvd.nist.gov/vuln/detail/CVE-2023-54237
---
 net/smc/af_smc.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/net/smc/af_smc.c b/net/smc/af_smc.c
index e9dabe758a31..e76e71417a2c 100644
--- a/net/smc/af_smc.c
+++ b/net/smc/af_smc.c
@@ -1303,8 +1303,10 @@ static int smcr_serv_conf_first_link(struct smc_sock *smc)
 	smc_llc_link_active(link);
 	smcr_lgr_set_type(link->lgr, SMC_LGR_SINGLE);
 
+	mutex_lock(&link->lgr->llc_conf_mutex);
 	/* initial contact - try to establish second link */
 	smc_llc_srv_add_link(link);
+	mutex_unlock(&link->lgr->llc_conf_mutex);
 	return 0;
 }
 
-- 
2.43.0

Re: [PATCH 5.10] net/smc: fix potential panic dues to unprotected smc_llc_srv_add_link()

[sashiko-bot]

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

Pre-existing issues:
- [High] Missing `llc_conf_mutex` lock around `smc_llc_cli_add_link()` on the client side.
- [High] Missing cancelation of `link_down_wrk` before clearing or freeing the link memory causes workqueue corruption and Use-After-Free.
--

commit 95b1079562e96ef6213155f37083256de0a0c01b
Author: D. Wythe <alibuda@linux.alibaba.com>

net/smc: fix potential panic dues to unprotected smc_llc_srv_add_link()

This commit fixes a potential panic when an SMC server creates a second
link. It adds llc_conf_mutex locking around smc_llc_srv_add_link() to
protect the link group from concurrent modifications.

Link: https://nvd.nist.gov/vuln/detail/CVE-2023-54237

> diff --git a/net/smc/af_smc.c b/net/smc/af_smc.c
> index 5dd4faaf7d6e5..fe6fb719a9a5f 100644
> --- a/net/smc/af_smc.c
> +++ b/net/smc/af_smc.c
> @@ -1268,8 +1268,10 @@ static int smcr_serv_conf_first_link(struct smc_sock *smc)
>  	smc_llc_link_active(link);
>  	smcr_lgr_set_type(link->lgr, SMC_LGR_SINGLE);
>  
> +	mutex_lock(&link->lgr->llc_conf_mutex);
>  	/* initial contact - try to establish second link */
>  	smc_llc_srv_add_link(link);
> +	mutex_unlock(&link->lgr->llc_conf_mutex);

[Severity: High]
This isn't a bug introduced by this patch, but does the client side need
this same locking?

Looking at smcr_clnt_conf_first_link() in the same file:

net/smc/af_smc.c:smcr_clnt_conf_first_link() {
    ...
        smc_llc_flow_qentry_clr(&link->lgr->llc_flow_lcl);
        smc_llc_cli_add_link(link, qentry);
        return 0;
}

It appears smc_llc_cli_add_link() modifies the link array without holding
llc_conf_mutex. Could this lead to the same panic if an asynchronous event
like smc_link_down_work() runs concurrently and operates on a partially
initialized link array?

>  	return 0;
>  }

[Severity: High]
This is another pre-existing issue, but I am wondering about the
cancelation of link_down_wrk when clearing a link.

In net/smc/smc_core.c:smcr_link_clear():

net/smc/smc_core.c:smcr_link_clear() {
    ...
        smcibdev = lnk->smcibdev;
        memset(lnk, 0, sizeof(struct smc_link));
        lnk->state = SMC_LNK_UNUSED;
    ...
}

If a device error triggers smcr_link_down_cond_sched() to queue
lnk->link_down_wrk, and the link group is terminated before the work
executes, could the memset() corrupt the workqueue by zeroing out its
linked list pointers?

If the link group is subsequently freed via smc_lgr_free(), could the
pending work then execute on freed memory? Should there be a
cancel_work_sync() for link_down_wrk before clearing the link memory?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260901090545.10419-1-arefev@swemel.ru?part=1

Re: [PATCH 5.10] net/smc: fix potential panic dues to unprotected smc_llc_srv_add_link()

[Dust Li]

On 2026-09-01 12:05:43, Denis Arefev wrote:
>From: "D. Wythe" <alibuda@linux.alibaba.com>
>
>commit e40b801b3603a8f90b46acbacdea3505c27f01c0 upstream.
>
>There is a certain chance to trigger the following panic:
>
>PID: 5900   TASK: ffff88c1c8af4100  CPU: 1   COMMAND: "kworker/1:48"
> #0 [ffff9456c1cc79a0] machine_kexec at ffffffff870665b7
> #1 [ffff9456c1cc79f0] __crash_kexec at ffffffff871b4c7a
> #2 [ffff9456c1cc7ab0] crash_kexec at ffffffff871b5b60
> #3 [ffff9456c1cc7ac0] oops_end at ffffffff87026ce7
> #4 [ffff9456c1cc7ae0] page_fault_oops at ffffffff87075715
> #5 [ffff9456c1cc7b58] exc_page_fault at ffffffff87ad0654
> #6 [ffff9456c1cc7b80] asm_exc_page_fault at ffffffff87c00b62
>    [exception RIP: ib_alloc_mr+19]
>    RIP: ffffffffc0c9cce3  RSP: ffff9456c1cc7c38  RFLAGS: 00010202
>    RAX: 0000000000000000  RBX: 0000000000000002  RCX: 0000000000000004
>    RDX: 0000000000000010  RSI: 0000000000000000  RDI: 0000000000000000
>    RBP: ffff88c1ea281d00   R8: 000000020a34ffff   R9: ffff88c1350bbb20
>    R10: 0000000000000000  R11: 0000000000000001  R12: 0000000000000000
>    R13: 0000000000000010  R14: ffff88c1ab040a50  R15: ffff88c1ea281d00
>    ORIG_RAX: ffffffffffffffff  CS: 0010  SS: 0018
> #7 [ffff9456c1cc7c60] smc_ib_get_memory_region at ffffffffc0aff6df [smc]
> #8 [ffff9456c1cc7c88] smcr_buf_map_link at ffffffffc0b0278c [smc]
> #9 [ffff9456c1cc7ce0] __smc_buf_create at ffffffffc0b03586 [smc]
>
>The reason here is that when the server tries to create a second link,
>smc_llc_srv_add_link() has no protection and may add a new link to
>link group. This breaks the security environment protected by
>llc_conf_mutex.
>
>Fixes: 2d2209f20189 ("net/smc: first part of add link processing as SMC server")
>Signed-off-by: D. Wythe <alibuda@linux.alibaba.com>
>Reviewed-by: Larysa Zaremba <larysa.zaremba@intel.com>
>Reviewed-by: Wenjia Zhang <wenjia@linux.ibm.com>
>Signed-off-by: David S. Miller <davem@davemloft.net>
>[Denis Arefev: adapted for 5.10: smc_llc_srv_add_link() has no 
>req_qentry argument here, as SMC-Rv2 REQ_ADD_LINK support is
>not present in 5.10]
>Signed-off-by: Denis Arefev <arefev@swemel.ru>

Reviewed-by: Dust Li <dust.li@linux.alibaba.com>

Best regards,
Dust