* [PATCH 5.10.y 0/2] net/smc: bound v2 extension offsets and counts in CLC proposal
@ 2026-09-20 5:14 Junjie Cao
2026-09-20 5:14 ` [PATCH 5.10.y 1/2] net/smc: check smcd_v2_ext_offset when receiving proposal msg Junjie Cao
` (2 more replies)
0 siblings, 3 replies; 6+ messages in thread
From: Junjie Cao @ 2026-09-20 5:14 UTC (permalink / raw)
To: stable
Cc: gregkh, sashal, guangguan.wang, alibuda, dust.li, sidraya,
mjambigi, tonylu, guwen, linux-rdma, linux-s390, netdev
5.10.y backport of the CVE-2024-49568 fix (patch 2), requested in the
6.1.y thread:
https://lore.kernel.org/r/20260918045353.686837-1-junjie.cao@intel.com
5.10.y also lacks 9ab332deb671 (CVE-2024-47408) from the same upstream
series; 5.15.y has it since v5.15.176. It goes first: the ism_gid_cnt
limit in patch 2 bounds the gidchid[] walk only once smcd_v2_ext
itself is inside the receive buffer. The diff is the same as the
5.15.y backport a36364d8d4fab.
Patch 2 has the same diff as the 5.15.y backport posted alongside.
Each commit builds net/smc on v5.10.270, x86_64, CONFIG_SMC=m, W=1
clean. Not runtime-tested.
Guangguan Wang (2):
net/smc: check smcd_v2_ext_offset when receiving proposal msg
net/smc: check v2_ext_offset/eid_cnt/ism_gid_cnt when receiving
proposal msg
net/smc/smc_clc.c | 8 +++++++-
net/smc/smc_clc.h | 17 +++++++++++++++--
2 files changed, 22 insertions(+), 3 deletions(-)
--
2.43.0
^ permalink raw reply [flat|nested] 6+ messages in thread
* [PATCH 5.10.y 1/2] net/smc: check smcd_v2_ext_offset when receiving proposal msg
2026-09-20 5:14 [PATCH 5.10.y 0/2] net/smc: bound v2 extension offsets and counts in CLC proposal Junjie Cao
@ 2026-09-20 5:14 ` Junjie Cao
2026-09-21 5:20 ` sashiko-bot
2026-09-20 5:16 ` [PATCH 5.10.y 2/2] net/smc: check v2_ext_offset/eid_cnt/ism_gid_cnt " Junjie Cao
2026-09-20 17:50 ` [PATCH 5.10.y 0/2] net/smc: bound v2 extension offsets and counts in CLC proposal Sasha Levin
2 siblings, 1 reply; 6+ messages in thread
From: Junjie Cao @ 2026-09-20 5:14 UTC (permalink / raw)
To: stable
Cc: gregkh, sashal, guangguan.wang, alibuda, dust.li, sidraya,
mjambigi, tonylu, guwen, linux-rdma, linux-s390, netdev,
David S . Miller
From: Guangguan Wang <guangguan.wang@linux.alibaba.com>
commit 9ab332deb671d8f7e66d82a2ff2b3f715bc3a4ad upstream.
When receiving proposal msg in server, the field smcd_v2_ext_offset in
proposal msg is from the remote client and can not be fully trusted.
Once the value of smcd_v2_ext_offset exceed the max value, there has
the chance to access wrong address, and crash may happen.
This patch checks the value of smcd_v2_ext_offset before using it.
Fixes: 5c21c4ccafe8 ("net/smc: determine accepted ISM devices")
Signed-off-by: Guangguan Wang <guangguan.wang@linux.alibaba.com>
Reviewed-by: Wen Gu <guwen@linux.alibaba.com>
Reviewed-by: D. Wythe <alibuda@linux.alibaba.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
[ jcao: drop the af_smc.c hunk, the !smcd_v2_ext test already there
covers it; result matches the 5.15.y backport a36364d8d4fab ]
Signed-off-by: Junjie Cao <junjie.cao@intel.com>
---
net/smc/smc_clc.h | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/net/smc/smc_clc.h b/net/smc/smc_clc.h
index a57a3489df4ae..f7f656b297f9c 100644
--- a/net/smc/smc_clc.h
+++ b/net/smc/smc_clc.h
@@ -306,9 +306,15 @@ smc_get_clc_v2_ext(struct smc_clc_msg_proposal *prop)
static inline struct smc_clc_smcd_v2_extension *
smc_get_clc_smcd_v2_ext(struct smc_clc_v2_extension *prop_v2ext)
{
+ u16 max_offset = offsetof(struct smc_clc_msg_proposal_area, pclc_smcd_v2_ext) -
+ offsetof(struct smc_clc_msg_proposal_area, pclc_v2_ext) -
+ offsetof(struct smc_clc_v2_extension, hdr) -
+ offsetofend(struct smc_clnt_opts_area_hdr, smcd_v2_ext_offset);
+
if (!prop_v2ext)
return NULL;
- if (!ntohs(prop_v2ext->hdr.smcd_v2_ext_offset))
+ if (!ntohs(prop_v2ext->hdr.smcd_v2_ext_offset) ||
+ ntohs(prop_v2ext->hdr.smcd_v2_ext_offset) > max_offset)
return NULL;
return (struct smc_clc_smcd_v2_extension *)
--
2.43.0
^ permalink raw reply related [flat|nested] 6+ messages in thread
* [PATCH 5.10.y 2/2] net/smc: check v2_ext_offset/eid_cnt/ism_gid_cnt when receiving proposal msg
2026-09-20 5:14 [PATCH 5.10.y 0/2] net/smc: bound v2 extension offsets and counts in CLC proposal Junjie Cao
2026-09-20 5:14 ` [PATCH 5.10.y 1/2] net/smc: check smcd_v2_ext_offset when receiving proposal msg Junjie Cao
@ 2026-09-20 5:16 ` Junjie Cao
2026-09-21 5:20 ` sashiko-bot
2026-09-20 17:50 ` [PATCH 5.10.y 0/2] net/smc: bound v2 extension offsets and counts in CLC proposal Sasha Levin
2 siblings, 1 reply; 6+ messages in thread
From: Junjie Cao @ 2026-09-20 5:16 UTC (permalink / raw)
To: stable
Cc: gregkh, sashal, guangguan.wang, alibuda, dust.li, sidraya,
mjambigi, tonylu, guwen, linux-rdma, linux-s390, netdev,
David S . Miller
From: Guangguan Wang <guangguan.wang@linux.alibaba.com>
commit 7863c9f3d24ba49dbead7e03dfbe40deb5888fdf upstream.
When receiving proposal msg in server, the fields v2_ext_offset/
eid_cnt/ism_gid_cnt in proposal msg are from the remote client
and can not be fully trusted. Especially the field v2_ext_offset,
once exceed the max value, there has the chance to access wrong
address, and crash may happen.
This patch checks the fields v2_ext_offset/eid_cnt/ism_gid_cnt
before using them.
Fixes: 8c3dca341aea ("net/smc: build and send V2 CLC proposal")
Signed-off-by: Guangguan Wang <guangguan.wang@linux.alibaba.com>
Reviewed-by: Wen Gu <guwen@linux.alibaba.com>
Reviewed-by: D. Wythe <alibuda@linux.alibaba.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
[ jcao: drop the af_smc.c hunk, smc_find_rdma_v2_device_serv() came
with SMC-Rv2 in e49300a6bf62 (v5.16); take SMC_CLC_MAX_UEID from
fa0866625543 (v5.16); SMC_MAX_ISM_DEVS is the pre-b40584d14570 name
of SMCD_CLC_MAX_V2_GID_ENTRIES ]
Signed-off-by: Junjie Cao <junjie.cao@intel.com>
---
net/smc/smc_clc.c | 8 +++++++-
net/smc/smc_clc.h | 9 ++++++++-
2 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/net/smc/smc_clc.c b/net/smc/smc_clc.c
index bdbe82b306c50..8d72865dd7fb1 100644
--- a/net/smc/smc_clc.c
+++ b/net/smc/smc_clc.c
@@ -47,7 +47,6 @@ static bool smc_clc_msg_prop_valid(struct smc_clc_msg_proposal *pclc)
struct smc_clc_msg_hdr *hdr = &pclc->hdr;
struct smc_clc_v2_extension *v2_ext;
- v2_ext = smc_get_clc_v2_ext(pclc);
pclc_prfx = smc_clc_proposal_get_prefix(pclc);
if (!pclc_prfx ||
pclc_prfx->ipv6_prefixes_cnt > SMC_CLC_MAX_V6_PREFIX)
@@ -64,6 +63,13 @@ static bool smc_clc_msg_prop_valid(struct smc_clc_msg_proposal *pclc)
sizeof(struct smc_clc_msg_trail))
return false;
} else {
+ v2_ext = smc_get_clc_v2_ext(pclc);
+ if ((hdr->typev2 != SMC_TYPE_N &&
+ (!v2_ext || v2_ext->hdr.eid_cnt > SMC_CLC_MAX_UEID)) ||
+ (smcd_indicated(hdr->typev2) &&
+ v2_ext->hdr.ism_gid_cnt > SMC_MAX_ISM_DEVS))
+ return false;
+
if (ntohs(hdr->length) !=
sizeof(*pclc) +
sizeof(struct smc_clc_msg_smcd) +
diff --git a/net/smc/smc_clc.h b/net/smc/smc_clc.h
index f7f656b297f9c..0c8e752f09f44 100644
--- a/net/smc/smc_clc.h
+++ b/net/smc/smc_clc.h
@@ -153,6 +153,7 @@ struct smc_clc_msg_proposal { /* clc proposal message sent by Linux */
} __aligned(4);
#define SMC_CLC_MAX_V6_PREFIX 8
+#define SMC_CLC_MAX_UEID 8
struct smc_clc_msg_proposal_area {
struct smc_clc_msg_proposal pclc_base;
@@ -292,8 +293,14 @@ static inline struct smc_clc_v2_extension *
smc_get_clc_v2_ext(struct smc_clc_msg_proposal *prop)
{
struct smc_clc_msg_smcd *prop_smcd = smc_get_clc_msg_smcd(prop);
+ u16 max_offset;
- if (!prop_smcd || !ntohs(prop_smcd->v2_ext_offset))
+ max_offset = offsetof(struct smc_clc_msg_proposal_area, pclc_v2_ext) -
+ offsetof(struct smc_clc_msg_proposal_area, pclc_smcd) -
+ offsetofend(struct smc_clc_msg_smcd, v2_ext_offset);
+
+ if (!prop_smcd || !ntohs(prop_smcd->v2_ext_offset) ||
+ ntohs(prop_smcd->v2_ext_offset) > max_offset)
return NULL;
return (struct smc_clc_v2_extension *)
--
2.43.0
^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH 5.10.y 0/2] net/smc: bound v2 extension offsets and counts in CLC proposal
2026-09-20 5:14 [PATCH 5.10.y 0/2] net/smc: bound v2 extension offsets and counts in CLC proposal Junjie Cao
2026-09-20 5:14 ` [PATCH 5.10.y 1/2] net/smc: check smcd_v2_ext_offset when receiving proposal msg Junjie Cao
2026-09-20 5:16 ` [PATCH 5.10.y 2/2] net/smc: check v2_ext_offset/eid_cnt/ism_gid_cnt " Junjie Cao
@ 2026-09-20 17:50 ` Sasha Levin
2 siblings, 0 replies; 6+ messages in thread
From: Sasha Levin @ 2026-09-20 17:50 UTC (permalink / raw)
To: stable
Cc: Sasha Levin, gregkh, guangguan.wang, alibuda, dust.li, sidraya,
mjambigi, tonylu, guwen, linux-rdma, linux-s390, netdev,
Junjie Cao
> 5.10.y also lacks 9ab332deb671 (CVE-2024-47408) from the same upstream
> series; 5.15.y has it since v5.15.176. It goes first: the ism_gid_cnt
> limit in patch 2 bounds the gidchid[] walk only once smcd_v2_ext
> itself is inside the receive buffer.
Queued the series for 5.10, thanks. The 5.15 half went in alongside it,
so the two trees are back in step.
--
Thanks,
Sasha
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH 5.10.y 2/2] net/smc: check v2_ext_offset/eid_cnt/ism_gid_cnt when receiving proposal msg
2026-09-20 5:16 ` [PATCH 5.10.y 2/2] net/smc: check v2_ext_offset/eid_cnt/ism_gid_cnt " Junjie Cao
@ 2026-09-21 5:20 ` sashiko-bot
0 siblings, 0 replies; 6+ messages in thread
From: sashiko-bot @ 2026-09-21 5:20 UTC (permalink / raw)
To: Junjie Cao
Cc: linux-s390, Heiko Carstens, Vasily Gorbik, Christian Borntraeger,
Alexander Gordeev, linux-rdma
> From: Guangguan Wang <guangguan.wang@linux.alibaba.com>
>
> commit 7863c9f3d24ba49dbead7e03dfbe40deb5888fdf upstream.
>
> When receiving proposal msg in server, the fields v2_ext_offset/
> eid_cnt/ism_gid_cnt in proposal msg are from the remote client
> and can not be fully trusted. Especially the field v2_ext_offset,
> once exceed the max value, there has the chance to access wrong
> address, and crash may happen.
>
> This patch checks the fields v2_ext_offset/eid_cnt/ism_gid_cnt
> before using them.
>
> Fixes: 8c3dca341aea ("net/smc: build and send V2 CLC proposal")
> Signed-off-by: Guangguan Wang <guangguan.wang@linux.alibaba.com>
> Reviewed-by: Wen Gu <guwen@linux.alibaba.com>
> Reviewed-by: D. Wythe <alibuda@linux.alibaba.com>
> Signed-off-by: David S. Miller <davem@davemloft.net>
> [ jcao: drop the af_smc.c hunk, smc_find_rdma_v2_device_serv() came
> with SMC-Rv2 in e49300a6bf62 (v5.16); take SMC_CLC_MAX_UEID from
> fa0866625543 (v5.16); SMC_MAX_ISM_DEVS is the pre-b40584d14570 name
> of SMCD_CLC_MAX_V2_GID_ENTRIES ]
> Signed-off-by: Junjie Cao <junjie.cao@intel.com>
Sashiko has reviewed this patch and found no issues. It looks great!
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260920051403.712116-1-junjie.cao@intel.com?part=2
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH 5.10.y 1/2] net/smc: check smcd_v2_ext_offset when receiving proposal msg
2026-09-20 5:14 ` [PATCH 5.10.y 1/2] net/smc: check smcd_v2_ext_offset when receiving proposal msg Junjie Cao
@ 2026-09-21 5:20 ` sashiko-bot
0 siblings, 0 replies; 6+ messages in thread
From: sashiko-bot @ 2026-09-21 5:20 UTC (permalink / raw)
To: Junjie Cao
Cc: Vasily Gorbik, linux-rdma, Heiko Carstens, Christian Borntraeger,
linux-s390, Alexander Gordeev
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] net/smc: protocol regression in SMCv2 proposal parsing due to static max_offset
--
commit 32692cd08a75040e1005cf9b8d09a85a6a7acc74
Author: Guangguan Wang <guangguan.wang@linux.alibaba.com>
net/smc: check smcd_v2_ext_offset when receiving proposal msg
When receiving proposal msg in server, the field smcd_v2_ext_offset in
proposal msg is from the remote client and can not be fully trusted.
Once the value of smcd_v2_ext_offset exceed the max value, there has
the chance to access wrong address, and crash may happen.
> diff --git a/net/smc/smc_clc.h b/net/smc/smc_clc.h
> index a57a3489df4ae..f7f656b297f9c 100644
> --- a/net/smc/smc_clc.h
> +++ b/net/smc/smc_clc.h
> @@ -306,9 +306,15 @@ smc_get_clc_v2_ext(struct smc_clc_msg_proposal *prop)
> static inline struct smc_clc_smcd_v2_extension *
> smc_get_clc_smcd_v2_ext(struct smc_clc_v2_extension *prop_v2ext)
> {
> + u16 max_offset = offsetof(struct smc_clc_msg_proposal_area, pclc_smcd_v2_ext) -
> + offsetof(struct smc_clc_msg_proposal_area, pclc_v2_ext) -
> + offsetof(struct smc_clc_v2_extension, hdr) -
> + offsetofend(struct smc_clnt_opts_area_hdr, smcd_v2_ext_offset);
> +
[Severity: High]
Does this static calculation ignore the dynamic size of the flexible
user_eids array in struct smc_clc_v2_extension?
By not accounting for the user_eids array, max_offset appears strictly
limited to the case where eid_cnt = 0.
> if (!prop_v2ext)
> return NULL;
> - if (!ntohs(prop_v2ext->hdr.smcd_v2_ext_offset))
> + if (!ntohs(prop_v2ext->hdr.smcd_v2_ext_offset) ||
> + ntohs(prop_v2ext->hdr.smcd_v2_ext_offset) > max_offset)
> return NULL;
[Severity: High]
Will this falsely flag valid offsets as out-of-bounds when the proposal
includes user EIDs?
When an untrusted remote peer initiates an SMC-D v2 connection proposing
one or more user EIDs (up to SMC_CLC_MAX_UEID), the packet may be
correctly sized and well-formed.
However, because max_offset ignores the flexible user_eids array, this
check returns NULL and drops the capability, breaking protocol compliance
and interoperability with SMCv2 peers that use Enterprise IDs.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260920051403.712116-1-junjie.cao@intel.com?part=1
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2026-09-21 5:20 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-09-20 5:14 [PATCH 5.10.y 0/2] net/smc: bound v2 extension offsets and counts in CLC proposal Junjie Cao
2026-09-20 5:14 ` [PATCH 5.10.y 1/2] net/smc: check smcd_v2_ext_offset when receiving proposal msg Junjie Cao
2026-09-21 5:20 ` sashiko-bot
2026-09-20 5:16 ` [PATCH 5.10.y 2/2] net/smc: check v2_ext_offset/eid_cnt/ism_gid_cnt " Junjie Cao
2026-09-21 5:20 ` sashiko-bot
2026-09-20 17:50 ` [PATCH 5.10.y 0/2] net/smc: bound v2 extension offsets and counts in CLC proposal Sasha Levin
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox