[PATCH net] net/smc: fix qentry overwrite for CONFIRM_LINK and ADD_LINK_CONT in smc_llc_event_handler()

[PATCH net] net/smc: fix qentry overwrite for CONFIRM_LINK and ADD_LINK_CONT in smc_llc_event_handler()

[Mahanta Jambigi]

The SMC_LLC_CONFIRM_LINK / SMC_LLC_ADD_LINK_CONT branch in
smc_llc_event_handler() stores an incoming qentry into the local LLC flow
without first checking whether a qentry is already pending. If a malicious or
buggy peer sends a second CONFIRM_LINK or ADD_LINK_CONT request while a flow is
active and flow->qentry is already set, smc_llc_flow_qentry_set() overwrites the
pointer without freeing the previous allocation, leaking one kmalloc-96 object
per spurious message.

The sibling SMC_LLC_DELETE_LINK branch already has the correct !flow->qentry
guard. Apply the same guard to the CONFIRM_LINK/ADD_LINK_CONT branch so that a
duplicate message when qentry is already occupied falls through to break and is
freed by the kfree(qentry) at the out: label, rather than silently leaking the
existing allocation.

The response direction (smc_llc_rx_response()) is unaffected: it already guards
with flow->qentry at the equivalent site and drops duplicate responses
correctly.

Fixes: 0fb0b02bd6fd ("net/smc: adapt SMC client code to use the LLC flow")
Signed-off-by: Mahanta Jambigi <mjambigi@linux.ibm.com>
Reviewed-by: Hidayath Khan <hidayath@linux.ibm.com>
Reviewed-by: Sidraya Jayagond <sidraya@linux.ibm.com>
---
 net/smc/smc_llc.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/net/smc/smc_llc.c b/net/smc/smc_llc.c
index 954b2ff1815c..aa6d83af55ed 100644
--- a/net/smc/smc_llc.c
+++ b/net/smc/smc_llc.c
@@ -1927,7 +1927,8 @@ static void smc_llc_event_handler(struct smc_llc_qentry *qentry)
 		return;
 	case SMC_LLC_CONFIRM_LINK:
 	case SMC_LLC_ADD_LINK_CONT:
-		if (lgr->llc_flow_lcl.type != SMC_LLC_FLOW_NONE) {
+		if (lgr->llc_flow_lcl.type != SMC_LLC_FLOW_NONE &&
+		    !lgr->llc_flow_lcl.qentry) {
 			/* a flow is waiting for this message */
 			smc_llc_flow_qentry_set(&lgr->llc_flow_lcl, qentry);
 			wake_up(&lgr->llc_msg_waiter);
-- 
2.53.0

Re: [PATCH net] net/smc: fix qentry overwrite for CONFIRM_LINK and ADD_LINK_CONT in smc_llc_event_handler()

[Dust Li]

On 2026-07-29 15:01:53, Mahanta Jambigi wrote:
>The SMC_LLC_CONFIRM_LINK / SMC_LLC_ADD_LINK_CONT branch in
>smc_llc_event_handler() stores an incoming qentry into the local LLC flow
>without first checking whether a qentry is already pending. If a malicious or
>buggy peer sends a second CONFIRM_LINK or ADD_LINK_CONT request while a flow is
>active and flow->qentry is already set, smc_llc_flow_qentry_set() overwrites the
>pointer without freeing the previous allocation, leaking one kmalloc-96 object
>per spurious message.
>
>The sibling SMC_LLC_DELETE_LINK branch already has the correct !flow->qentry
>guard. Apply the same guard to the CONFIRM_LINK/ADD_LINK_CONT branch so that a
>duplicate message when qentry is already occupied falls through to break and is
>freed by the kfree(qentry) at the out: label, rather than silently leaking the
>existing allocation.
>
>The response direction (smc_llc_rx_response()) is unaffected: it already guards
>with flow->qentry at the equivalent site and drops duplicate responses
>correctly.
>
>Fixes: 0fb0b02bd6fd ("net/smc: adapt SMC client code to use the LLC flow")
>Signed-off-by: Mahanta Jambigi <mjambigi@linux.ibm.com>
>Reviewed-by: Hidayath Khan <hidayath@linux.ibm.com>
>Reviewed-by: Sidraya Jayagond <sidraya@linux.ibm.com>
>---
> net/smc/smc_llc.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
>diff --git a/net/smc/smc_llc.c b/net/smc/smc_llc.c
>index 954b2ff1815c..aa6d83af55ed 100644
>--- a/net/smc/smc_llc.c
>+++ b/net/smc/smc_llc.c
>@@ -1927,7 +1927,8 @@ static void smc_llc_event_handler(struct smc_llc_qentry *qentry)
> 		return;
> 	case SMC_LLC_CONFIRM_LINK:
> 	case SMC_LLC_ADD_LINK_CONT:
>-		if (lgr->llc_flow_lcl.type != SMC_LLC_FLOW_NONE) {
>+		if (lgr->llc_flow_lcl.type != SMC_LLC_FLOW_NONE &&
>+		    !lgr->llc_flow_lcl.qentry) {


I read sashiko's review comments, and I think both of them make sense, but
they were pre-existing issues. So I think we can solve them in the future
patches.

https://sashiko.dev/#/patchset/20260729130153.970800-1-mjambigi@linux.ibm.com

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

Best regards,
Dust