* [PATCH net v4 0/3] net/smc: fix out-of-bounds and use-after-free in SMC-Rv2 LLC processing
@ 2026-07-31 7:05 Yehyeong Lee
2026-07-31 7:05 ` [PATCH net v4 1/3] net/smc: fix use-after-free of the LLC qentry in smc_llc_srv_add_link() Yehyeong Lee
` (2 more replies)
0 siblings, 3 replies; 8+ messages in thread
From: Yehyeong Lee @ 2026-07-31 7:05 UTC (permalink / raw)
To: alibuda, dust.li, sidraya, wenjia, kuba, davem, edumazet, pabeni
Cc: horms, mjambigi, tonylu, guwen, guangguan.wang, kees, gustavoars,
netdev, linux-rdma, linux-s390, linux-hardening, linux-kernel,
Yehyeong Lee
Split of the single v3 patch, in the order Jakub asked for:
1/3 frees the LLC queue entry in smc_llc_srv_add_link() only after the
last use of the pointer into it.
2/3 bounds the peer-declared rkey counts in smc_llc_save_add_link_rkeys()
and smc_llc_rmt_delete_rkey() by the buffer they read from.
3/3 copies an oversized SMC-Rv2 LLC message into the queue entry and
declares the rkeys that fit inline, so both consumers stop
reconstructing the layout themselves.
1/3 and 2/3 are tagged for stable. 3/3 is not: it does not fix a crash on
its own, and it changes a structure layout and a static function signature.
---
v3: https://lore.kernel.org/all/20260727095833.1079618-1-yhlee@isslab.korea.ac.kr/
Yehyeong Lee (3):
net/smc: fix use-after-free of the LLC qentry in
smc_llc_srv_add_link()
net/smc: bound the peer rkey counts in SMC-Rv2 LLC messages
net/smc: carry oversized SMC-Rv2 LLC messages in the queue entry
net/smc/smc_llc.c | 101 ++++++++++++++++++++++++++++++++++------------
1 file changed, 76 insertions(+), 25 deletions(-)
--
2.43.0
^ permalink raw reply [flat|nested] 8+ messages in thread
* [PATCH net v4 1/3] net/smc: fix use-after-free of the LLC qentry in smc_llc_srv_add_link()
2026-07-31 7:05 [PATCH net v4 0/3] net/smc: fix out-of-bounds and use-after-free in SMC-Rv2 LLC processing Yehyeong Lee
@ 2026-07-31 7:05 ` Yehyeong Lee
2026-08-01 7:05 ` sashiko-bot
2026-07-31 7:05 ` [PATCH net v4 2/3] net/smc: bound the peer rkey counts in SMC-Rv2 LLC messages Yehyeong Lee
2026-07-31 7:05 ` [PATCH net v4 3/3] net/smc: carry oversized SMC-Rv2 LLC messages in the queue entry Yehyeong Lee
2 siblings, 1 reply; 8+ messages in thread
From: Yehyeong Lee @ 2026-07-31 7:05 UTC (permalink / raw)
To: alibuda, dust.li, sidraya, wenjia, kuba, davem, edumazet, pabeni
Cc: horms, mjambigi, tonylu, guwen, guangguan.wang, kees, gustavoars,
netdev, linux-rdma, linux-s390, linux-hardening, linux-kernel,
Yehyeong Lee, stable
smc_llc_srv_add_link() keeps add_llc pointing into the queue entry:
add_llc = &qentry->msg.add_link; smc_llc.c:1482
...
smc_llc_save_add_link_info(link_new, add_llc); smc_llc.c:1494
smc_llc_flow_qentry_del(&lgr->llc_flow_lcl); smc_llc.c:1495
...
u8 *llc_msg = smc_link_shared_v2_rxbuf(link) ?
(u8 *)lgr->wr_rx_buf_v2 : (u8 *)add_llc; smc_llc.c:1504
smc_llc_save_add_link_rkeys(link, link_new, llc_msg); smc_llc.c:1506
smc_llc_flow_qentry_del() kfree()s the entry, so on a link without a shared
v2 receive buffer the pointer handed to smc_llc_save_add_link_rkeys() is
already freed. Before the Fixes: commit that branch always used
lgr->wr_rx_buf_v2 and add_llc was not used after the free.
Detach the entry instead of freeing it there, and free it explicitly on
both exit paths. The reject path has to detach as well, otherwise it would
be freed twice.
Fixes: 27ef6a9981fe ("net/smc: support SMC-R V2 for rdma devices with max_recv_sge equals to 1")
Cc: stable@vger.kernel.org
Signed-off-by: Yehyeong Lee <yhlee@isslab.korea.ac.kr>
---
Reproduced on an unpatched tree over rxe, with KASAN, kasan_multi_shot and a
link forced to max_recv_sge == 1: the entry is freed and read by the same
call, and the freeing frame is smc_llc_srv_add_link() itself.
BUG: KASAN: slab-use-after-free in smc_llc_save_add_link_rkeys+0x333/0x350
Read of size 2 at addr ffff8880052194de by task kworker/0:1/11
Workqueue: smc_hs_wq smc_listen_work
smc_llc_save_add_link_rkeys+0x333/0x350
smc_llc_srv_add_link+0xaa2/0x1e50
smc_listen_work+0x489e/0x4d00
Allocated by task 48:
smc_llc_enqueue+0x72/0x560
smc_wr_rx_tasklet_fn+0x474/0xa80
Freed by task 11:
kfree+0x121/0x380
smc_llc_srv_add_link+0x9a8/0x1e50
smc_listen_work+0x489e/0x4d00
The buggy address is located 94 bytes inside of
freed 96-byte region [ffff888005219480, ffff8880052194e0)
The offset is past the 72-byte queue entry because the out-of-bounds read
fixed by the next patch is on the same line; what this patch removes is the
free at smc_llc_srv_add_link+0x9a8 happening before the read at +0xaa2.
net/smc/smc_llc.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/net/smc/smc_llc.c b/net/smc/smc_llc.c
index 954b2ff1815c..90746cd1e29a 100644
--- a/net/smc/smc_llc.c
+++ b/net/smc/smc_llc.c
@@ -1481,7 +1481,7 @@ int smc_llc_srv_add_link(struct smc_link *link,
}
add_llc = &qentry->msg.add_link;
if (add_llc->hd.flags & SMC_LLC_FLAG_ADD_LNK_REJ) {
- smc_llc_flow_qentry_del(&lgr->llc_flow_lcl);
+ smc_llc_flow_qentry_clr(&lgr->llc_flow_lcl);
rc = -ENOLINK;
goto out_err;
}
@@ -1492,7 +1492,8 @@ int smc_llc_srv_add_link(struct smc_link *link,
lgr_new_t = SMC_LGR_ASYMMETRIC_PEER;
}
smc_llc_save_add_link_info(link_new, add_llc);
- smc_llc_flow_qentry_del(&lgr->llc_flow_lcl);
+ /* add_llc still points into qentry, so only detach it here */
+ smc_llc_flow_qentry_clr(&lgr->llc_flow_lcl);
rc = smc_ib_ready_link(link_new);
if (rc)
@@ -1512,6 +1513,7 @@ int smc_llc_srv_add_link(struct smc_link *link,
rc = smc_llc_srv_conf_link(link, link_new, lgr_new_t);
if (rc)
goto out_err;
+ kfree(qentry);
kfree(ini);
return 0;
out_err:
@@ -1520,6 +1522,7 @@ int smc_llc_srv_add_link(struct smc_link *link,
smcr_link_clear(link_new, false);
}
out:
+ kfree(qentry);
kfree(ini);
if (send_req_add_link_resp)
smc_llc_send_req_add_link_response(req_qentry);
--
2.43.0
^ permalink raw reply related [flat|nested] 8+ messages in thread
* [PATCH net v4 2/3] net/smc: bound the peer rkey counts in SMC-Rv2 LLC messages
2026-07-31 7:05 [PATCH net v4 0/3] net/smc: fix out-of-bounds and use-after-free in SMC-Rv2 LLC processing Yehyeong Lee
2026-07-31 7:05 ` [PATCH net v4 1/3] net/smc: fix use-after-free of the LLC qentry in smc_llc_srv_add_link() Yehyeong Lee
@ 2026-07-31 7:05 ` Yehyeong Lee
2026-08-01 7:05 ` sashiko-bot
2026-07-31 7:05 ` [PATCH net v4 3/3] net/smc: carry oversized SMC-Rv2 LLC messages in the queue entry Yehyeong Lee
2 siblings, 1 reply; 8+ messages in thread
From: Yehyeong Lee @ 2026-07-31 7:05 UTC (permalink / raw)
To: alibuda, dust.li, sidraya, wenjia, kuba, davem, edumazet, pabeni
Cc: horms, mjambigi, tonylu, guwen, guangguan.wang, kees, gustavoars,
netdev, linux-rdma, linux-s390, linux-hardening, linux-kernel,
Yehyeong Lee, stable
On a link whose device has max_recv_sge == 1 there is no shared v2 receive
buffer, and smc_llc_save_add_link_rkeys() takes the v2 extension from 44
bytes past the start of the queue entry's inline message:
ext = (struct smc_llc_msg_add_link_v2_ext *)(llc_msg + SMC_WR_TX_SIZE);
The entry is a 72-byte allocation and the extension starts at offset 68, so
ext->num_rkeys at offset 94 is already past it. This happens on every
SMC-Rv2 link addition, whatever the peer sends:
BUG: KASAN: slab-out-of-bounds in smc_llc_save_add_link_rkeys+0x333/0x350
Read of size 2 at addr ffff8880056406de by task smctest/106
Call Trace:
smc_llc_save_add_link_rkeys+0x333/0x350
smc_llc_cli_add_link+0xca7/0x1e80
__smc_connect+0x3f5c/0x4980
smc_connect+0x42c/0x580
__sys_connect+0xfc/0x130
Allocated by task 44:
smc_llc_enqueue+0x72/0x560
smc_wr_rx_tasklet_fn+0x474/0xa80
The buggy address is located 22 bytes to the right of
allocated 72-byte region [ffff888005640680, ffff8880056406c8)
Whatever that read finds then bounds the ext->rt[] loop, so a peer that
declares 255 rkeys reads much further. smc_llc_rmt_delete_rkey() has the
same shape for llcv2->rkey[].
Bound both loops by the buffer they read from, and skip the extension
altogether when there is no shared v2 receive buffer, because nothing
beyond the 44 inline bytes was received in that case.
Fixes: 27ef6a9981fe ("net/smc: support SMC-R V2 for rdma devices with max_recv_sge equals to 1")
Cc: stable@vger.kernel.org
Signed-off-by: Yehyeong Lee <yhlee@isslab.korea.ac.kr>
---
Measured over rxe with KASAN and max_recv_sge forced to 1, five test cells
(plain 1-rkey delete, delete declaring 255, plain ADD_LINK v2, ADD_LINK
declaring 255, and an SMC-Rv1 link group). Without this patch four of the
five report; with it none do. With kasan_multi_shot the unpatched kernel
reports 491 times in a single ADD_LINK run, the patched one not at all.
net/smc/smc_llc.c | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
diff --git a/net/smc/smc_llc.c b/net/smc/smc_llc.c
index 90746cd1e29a..606d2dc8c7ec 100644
--- a/net/smc/smc_llc.c
+++ b/net/smc/smc_llc.c
@@ -1000,13 +1000,22 @@ static void smc_llc_save_add_link_rkeys(struct smc_link *link,
struct smc_link *link_new,
u8 *llc_msg)
{
+ const u32 rt_off = offsetof(struct smc_llc_msg_add_link_v2_ext, rt);
struct smc_llc_msg_add_link_v2_ext *ext;
struct smc_link_group *lgr = link->lgr;
int max, i;
+ /* The extension follows the 44 bytes of the LLC message. Without a
+ * shared v2 receive buffer nothing beyond those 44 bytes was received,
+ * so not even ext->num_rkeys is there to be read.
+ */
+ if (!smc_link_shared_v2_rxbuf(link))
+ return;
ext = (struct smc_llc_msg_add_link_v2_ext *)(llc_msg +
SMC_WR_TX_SIZE);
max = min_t(u8, ext->num_rkeys, SMC_LLC_RKEYS_PER_MSG_V2);
+ max = min_t(u32, max, (SMC_WR_BUF_V2_SIZE - SMC_WR_TX_SIZE - rt_off) /
+ sizeof(ext->rt[0]));
down_write(&lgr->rmbs_lock);
for (i = 0; i < max; i++) {
smc_rtoken_set(lgr, link->link_idx, link_new->link_idx,
@@ -1813,17 +1822,27 @@ static void smc_llc_rmt_delete_rkey(struct smc_link_group *lgr)
link = qentry->link;
if (lgr->smc_version == SMC_V2) {
+ const u32 rkey_off =
+ offsetof(struct smc_llc_msg_delete_rkey_v2, rkey);
struct smc_llc_msg_delete_rkey_v2 *llcv2;
+ u32 buf_len;
if (smc_link_shared_v2_rxbuf(link)) {
memcpy(lgr->wr_rx_buf_v2, llc, sizeof(*llc));
llcv2 = (struct smc_llc_msg_delete_rkey_v2 *)lgr->wr_rx_buf_v2;
+ buf_len = SMC_WR_BUF_V2_SIZE;
} else {
llcv2 = (struct smc_llc_msg_delete_rkey_v2 *)llc;
+ buf_len = sizeof(qentry->msg);
}
llcv2->num_inval_rkeys = 0;
max = min_t(u8, llcv2->num_rkeys, SMC_LLC_RKEYS_PER_MSG_V2);
+ /* the rkeys live in the buffer llcv2 points at, and nothing
+ * beyond it was received
+ */
+ max = min_t(u32, max, (buf_len - rkey_off) /
+ sizeof(llcv2->rkey[0]));
for (i = 0; i < max; i++) {
if (smc_rtoken_delete(link, llcv2->rkey[i]))
llcv2->num_inval_rkeys++;
--
2.43.0
^ permalink raw reply related [flat|nested] 8+ messages in thread
* [PATCH net v4 3/3] net/smc: carry oversized SMC-Rv2 LLC messages in the queue entry
2026-07-31 7:05 [PATCH net v4 0/3] net/smc: fix out-of-bounds and use-after-free in SMC-Rv2 LLC processing Yehyeong Lee
2026-07-31 7:05 ` [PATCH net v4 1/3] net/smc: fix use-after-free of the LLC qentry in smc_llc_srv_add_link() Yehyeong Lee
2026-07-31 7:05 ` [PATCH net v4 2/3] net/smc: bound the peer rkey counts in SMC-Rv2 LLC messages Yehyeong Lee
@ 2026-07-31 7:05 ` Yehyeong Lee
2026-08-01 7:05 ` sashiko-bot
2 siblings, 1 reply; 8+ messages in thread
From: Yehyeong Lee @ 2026-07-31 7:05 UTC (permalink / raw)
To: alibuda, dust.li, sidraya, wenjia, kuba, davem, edumazet, pabeni
Cc: horms, mjambigi, tonylu, guwen, guangguan.wang, kees, gustavoars,
netdev, linux-rdma, linux-s390, linux-hardening, linux-kernel,
Yehyeong Lee
An LLC message longer than the 44-byte union smc_llc_msg arrives either
whole in the receive buffer or split into the link group's shared v2
buffer, and both consumers of the tail rebuild that layout themselves.
Copy the tail into the queue entry instead, so its length and its lifetime
are those of the message that arrived, and declare the rkeys that do fit
inline as a member of the union rather than reaching them through a cast of
a shorter type.
The bound the previous patch placed on links without a shared v2 receive
buffer is no longer needed here: the extension is read from the qentry,
whose length is the length of the message that arrived.
A DELETE_RKEY_V2 is now bounded by what arrived rather than by the buffer
it landed in: a 44-byte message declaring 255 rkeys processed 255 of them
before, and processes the 9 that fit now.
Suggested-by: D. Wythe <alibuda@linux.alibaba.com>
Signed-off-by: Yehyeong Lee <yhlee@isslab.korea.ac.kr>
---
Measured over rxe with KASAN: a DELETE_RKEY_V2 carrying 12 rkeys over a link
with a shared v2 receive buffer round-trips all 12 values, the last three
coming from the copied tail; 8, 9 and 10 rkeys and a 44-byte message declaring
10 give 8, 9, 10 and 9 processed rkeys respectively. kmemleak reports nothing
over the link-addition path, and does report the queue entry when the free
added by patch 1 is removed again.
net/smc/smc_llc.c | 109 +++++++++++++++++++++++++++++-----------------
1 file changed, 69 insertions(+), 40 deletions(-)
diff --git a/net/smc/smc_llc.c b/net/smc/smc_llc.c
index 606d2dc8c7ec..1b153173dd51 100644
--- a/net/smc/smc_llc.c
+++ b/net/smc/smc_llc.c
@@ -157,6 +157,7 @@ struct smc_llc_msg_confirm_rkey { /* type 0x06 */
};
#define SMC_LLC_DEL_RKEY_MAX 8
+#define SMC_LLC_DEL_RKEY_V2_INLINE 9
#define SMC_LLC_FLAG_RKEY_RETRY 0x10
#define SMC_LLC_FLAG_RKEY_NEG 0x20
@@ -177,6 +178,15 @@ struct smc_llc_msg_delete_rkey_v2 { /* type 0x29 */
__be32 rkey[];
};
+/* the leading rkeys of a DELETE_RKEY_V2 fit into union smc_llc_msg */
+struct smc_llc_msg_delete_rkey_v2_inline { /* type 0x29 */
+ struct smc_llc_hdr hd;
+ u8 num_rkeys;
+ u8 num_inval_rkeys;
+ u8 reserved[2];
+ __be32 rkey[SMC_LLC_DEL_RKEY_V2_INLINE];
+};
+
union smc_llc_msg {
struct smc_llc_msg_confirm_link confirm_link;
struct smc_llc_msg_add_link add_link;
@@ -186,6 +196,7 @@ union smc_llc_msg {
struct smc_llc_msg_confirm_rkey confirm_rkey;
struct smc_llc_msg_delete_rkey delete_rkey;
+ struct smc_llc_msg_delete_rkey_v2_inline delete_rkey_v2;
struct smc_llc_msg_test_link test_link;
struct {
@@ -194,15 +205,23 @@ union smc_llc_msg {
} raw;
};
+static_assert(SMC_LLC_DEL_RKEY_V2_INLINE ==
+ (sizeof(union smc_llc_msg) -
+ offsetof(struct smc_llc_msg_delete_rkey_v2, rkey)) /
+ sizeof(__be32));
+
#define SMC_LLC_FLAG_RESP 0x80
struct smc_llc_qentry {
struct list_head list;
struct smc_link *link;
+ u16 body_len;
union smc_llc_msg msg;
+ u8 body[] __counted_by(body_len);
};
-static void smc_llc_enqueue(struct smc_link *link, union smc_llc_msg *llc);
+static void smc_llc_enqueue(struct smc_link *link, union smc_llc_msg *llc,
+ u32 byte_len);
struct smc_llc_qentry *smc_llc_flow_qentry_clr(struct smc_llc_flow *flow)
{
@@ -998,23 +1017,19 @@ static int smc_llc_cli_conf_link(struct smc_link *link,
static void smc_llc_save_add_link_rkeys(struct smc_link *link,
struct smc_link *link_new,
- u8 *llc_msg)
+ struct smc_llc_qentry *qentry)
{
const u32 rt_off = offsetof(struct smc_llc_msg_add_link_v2_ext, rt);
struct smc_llc_msg_add_link_v2_ext *ext;
struct smc_link_group *lgr = link->lgr;
int max, i;
- /* The extension follows the 44 bytes of the LLC message. Without a
- * shared v2 receive buffer nothing beyond those 44 bytes was received,
- * so not even ext->num_rkeys is there to be read.
- */
- if (!smc_link_shared_v2_rxbuf(link))
+ /* the rkey count itself is only there if enough bytes arrived */
+ if (qentry->body_len < rt_off)
return;
- ext = (struct smc_llc_msg_add_link_v2_ext *)(llc_msg +
- SMC_WR_TX_SIZE);
+ ext = (struct smc_llc_msg_add_link_v2_ext *)qentry->body;
max = min_t(u8, ext->num_rkeys, SMC_LLC_RKEYS_PER_MSG_V2);
- max = min_t(u32, max, (SMC_WR_BUF_V2_SIZE - SMC_WR_TX_SIZE - rt_off) /
+ max = min_t(u32, max, (qentry->body_len - rt_off) /
sizeof(ext->rt[0]));
down_write(&lgr->rmbs_lock);
for (i = 0; i < max; i++) {
@@ -1108,9 +1123,7 @@ int smc_llc_cli_add_link(struct smc_link *link, struct smc_llc_qentry *qentry)
if (rc)
goto out_clear_lnk;
if (lgr->smc_version == SMC_V2) {
- u8 *llc_msg = smc_link_shared_v2_rxbuf(link) ?
- (u8 *)lgr->wr_rx_buf_v2 : (u8 *)llc;
- smc_llc_save_add_link_rkeys(link, lnk_new, llc_msg);
+ smc_llc_save_add_link_rkeys(link, lnk_new, qentry);
} else {
rc = smc_llc_cli_rkey_exchange(link, lnk_new);
if (rc) {
@@ -1511,9 +1524,7 @@ int smc_llc_srv_add_link(struct smc_link *link,
if (rc)
goto out_err;
if (lgr->smc_version == SMC_V2) {
- u8 *llc_msg = smc_link_shared_v2_rxbuf(link) ?
- (u8 *)lgr->wr_rx_buf_v2 : (u8 *)add_llc;
- smc_llc_save_add_link_rkeys(link, link_new, llc_msg);
+ smc_llc_save_add_link_rkeys(link, link_new, qentry);
} else {
rc = smc_llc_srv_rkey_exchange(link, link_new);
if (rc)
@@ -1564,7 +1575,8 @@ void smc_llc_add_link_local(struct smc_link *link)
add_llc.hd.common.llc_type = SMC_LLC_ADD_LINK;
smc_llc_init_msg_hdr(&add_llc.hd, link->lgr, sizeof(add_llc));
/* no dev and port needed */
- smc_llc_enqueue(link, (union smc_llc_msg *)&add_llc);
+ smc_llc_enqueue(link, (union smc_llc_msg *)&add_llc,
+ sizeof(union smc_llc_msg));
}
/* worker to process an add link message */
@@ -1600,7 +1612,8 @@ void smc_llc_srv_delete_link_local(struct smc_link *link, u8 del_link_id)
del_llc.link_num = del_link_id;
del_llc.reason = htonl(SMC_LLC_DEL_LOST_PATH);
del_llc.hd.flags |= SMC_LLC_FLAG_DEL_LINK_ORDERLY;
- smc_llc_enqueue(link, (union smc_llc_msg *)&del_llc);
+ smc_llc_enqueue(link, (union smc_llc_msg *)&del_llc,
+ sizeof(union smc_llc_msg));
}
static void smc_llc_process_cli_delete_link(struct smc_link_group *lgr)
@@ -1822,29 +1835,28 @@ static void smc_llc_rmt_delete_rkey(struct smc_link_group *lgr)
link = qentry->link;
if (lgr->smc_version == SMC_V2) {
- const u32 rkey_off =
- offsetof(struct smc_llc_msg_delete_rkey_v2, rkey);
- struct smc_llc_msg_delete_rkey_v2 *llcv2;
- u32 buf_len;
-
- if (smc_link_shared_v2_rxbuf(link)) {
- memcpy(lgr->wr_rx_buf_v2, llc, sizeof(*llc));
- llcv2 = (struct smc_llc_msg_delete_rkey_v2 *)lgr->wr_rx_buf_v2;
- buf_len = SMC_WR_BUF_V2_SIZE;
- } else {
- llcv2 = (struct smc_llc_msg_delete_rkey_v2 *)llc;
- buf_len = sizeof(qentry->msg);
- }
+ struct smc_llc_msg_delete_rkey_v2_inline *llcv2;
+
+ /* The leading SMC_LLC_DEL_RKEY_V2_INLINE rkeys are declared in
+ * the message itself, any further ones were received into
+ * qentry->body.
+ */
+ llcv2 = &qentry->msg.delete_rkey_v2;
llcv2->num_inval_rkeys = 0;
max = min_t(u8, llcv2->num_rkeys, SMC_LLC_RKEYS_PER_MSG_V2);
- /* the rkeys live in the buffer llcv2 points at, and nothing
- * beyond it was received
- */
- max = min_t(u32, max, (buf_len - rkey_off) /
- sizeof(llcv2->rkey[0]));
+ max = min_t(u32, max, SMC_LLC_DEL_RKEY_V2_INLINE +
+ qentry->body_len / sizeof(__be32));
for (i = 0; i < max; i++) {
- if (smc_rtoken_delete(link, llcv2->rkey[i]))
+ __be32 rkey;
+
+ if (i < SMC_LLC_DEL_RKEY_V2_INLINE)
+ rkey = llcv2->rkey[i];
+ else
+ memcpy(&rkey, qentry->body +
+ (i - SMC_LLC_DEL_RKEY_V2_INLINE) *
+ sizeof(rkey), sizeof(rkey));
+ if (smc_rtoken_delete(link, rkey))
llcv2->num_inval_rkeys++;
}
memset(&llc->rkey[0], 0, sizeof(llc->rkey));
@@ -2085,18 +2097,35 @@ static void smc_llc_rx_response(struct smc_link *link,
wake_up(&link->lgr->llc_msg_waiter);
}
-static void smc_llc_enqueue(struct smc_link *link, union smc_llc_msg *llc)
+static void smc_llc_enqueue(struct smc_link *link, union smc_llc_msg *llc,
+ u32 byte_len)
{
struct smc_link_group *lgr = link->lgr;
struct smc_llc_qentry *qentry;
unsigned long flags;
+ u16 body_len = 0;
- qentry = kmalloc_obj(*qentry, GFP_ATOMIC);
+ /* V2 messages can be longer than the inline union smc_llc_msg. Carry
+ * the remainder in the qentry itself, so that its lifetime and its
+ * length match the message the peer actually sent.
+ */
+ if (lgr->smc_version == SMC_V2 && byte_len > SMC_WR_TX_SIZE)
+ body_len = min_t(u32, byte_len, SMC_WR_BUF_V2_SIZE) -
+ SMC_WR_TX_SIZE;
+
+ qentry = kmalloc_flex(*qentry, body, body_len, GFP_ATOMIC);
if (!qentry)
return;
+ qentry->body_len = body_len;
qentry->link = link;
INIT_LIST_HEAD(&qentry->list);
memcpy(&qentry->msg, llc, sizeof(union smc_llc_msg));
+ if (body_len) {
+ u8 *src = smc_link_shared_v2_rxbuf(link) ?
+ (u8 *)lgr->wr_rx_buf_v2 : (u8 *)llc;
+
+ memcpy(qentry->body, src + SMC_WR_TX_SIZE, body_len);
+ }
/* process responses immediately */
if ((llc->raw.hdr.flags & SMC_LLC_FLAG_RESP) &&
@@ -2128,7 +2157,7 @@ static void smc_llc_rx_handler(struct ib_wc *wc, void *buf)
return; /* invalid message */
}
- smc_llc_enqueue(link, llc);
+ smc_llc_enqueue(link, llc, wc->byte_len);
}
/***************************** worker, utils *********************************/
--
2.43.0
^ permalink raw reply related [flat|nested] 8+ messages in thread
* Re: [PATCH net v4 2/3] net/smc: bound the peer rkey counts in SMC-Rv2 LLC messages
2026-07-31 7:05 ` [PATCH net v4 2/3] net/smc: bound the peer rkey counts in SMC-Rv2 LLC messages Yehyeong Lee
@ 2026-08-01 7:05 ` sashiko-bot
2026-08-01 9:10 ` Yehyeong Lee
0 siblings, 1 reply; 8+ messages in thread
From: sashiko-bot @ 2026-08-01 7:05 UTC (permalink / raw)
To: Yehyeong Lee; +Cc: linux-s390, Vasily Gorbik, Heiko Carstens, Alexander Gordeev
Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:
New issues:
- [High] The patch breaks SMC-R V2 connection setups and rkey deletions for devices with `max_recv_sge == 1` by intentionally discarding valid extension data under a false assumption.
Pre-existing issues:
- [High] The parsing loops process uninitialized or stale memory because they validate against buffer capacity rather than actual received network length.
- [High] Lockless modification of shared `lgr->rtokens` array and bitmap by `smc_rtoken_delete` and `smc_rtoken_add`.
- [High] CPU writes to a buffer mapped for DMA_FROM_DEVICE that is actively exposed to the hardware receive queue.
--
--- Patch [2]: [PATCH net v4 2/3] net/smc: bound the peer rkey counts in SMC-Rv2 LLC messages ---
commit 3af7503159894578c914029204c5f338ebbaaf3d
Author: Yehyeong Lee <yhlee@isslab.korea.ac.kr>
net/smc: bound the peer rkey counts in SMC-Rv2 LLC messages
This patch bounds the rkey extraction loops in SMC-Rv2 LLC messages to
the buffer size to prevent slab-out-of-bounds reads. It also skips the
extension processing entirely for devices without a shared v2 receive
buffer, under the assumption that nothing beyond the 44 inline bytes
was received.
> diff --git a/net/smc/smc_llc.c b/net/smc/smc_llc.c
> index 90746cd1e29a3..606d2dc8c7ece 100644
> --- a/net/smc/smc_llc.c
> +++ b/net/smc/smc_llc.c
> @@ -1000,13 +1000,22 @@ static void smc_llc_save_add_link_rkeys(struct smc_link *link,
> struct smc_link *link_new,
> u8 *llc_msg)
> {
> + const u32 rt_off = offsetof(struct smc_llc_msg_add_link_v2_ext, rt);
> struct smc_llc_msg_add_link_v2_ext *ext;
> struct smc_link_group *lgr = link->lgr;
> int max, i;
>
> + /* The extension follows the 44 bytes of the LLC message. Without a
> + * shared v2 receive buffer nothing beyond those 44 bytes was received,
> + * so not even ext->num_rkeys is there to be read.
> + */
> + if (!smc_link_shared_v2_rxbuf(link))
> + return;
[Severity: High]
Does this early return cause a permanent protocol failure for devices with a
single receive SGE?
It appears that when max_recv_sge == 1, lnk->wr_rx_buflen is configured to
8192 bytes, meaning the single SGE actually does receive the full extension
data from the hardware.
By dropping the data here under the assumption that it wasn't received, does
this silently break the protocol and cause peers to get Remote Access Errors
during RDMA writes because the rkeys are never registered?
> ext = (struct smc_llc_msg_add_link_v2_ext *)(llc_msg +
> SMC_WR_TX_SIZE);
> max = min_t(u8, ext->num_rkeys, SMC_LLC_RKEYS_PER_MSG_V2);
> + max = min_t(u32, max, (SMC_WR_BUF_V2_SIZE - SMC_WR_TX_SIZE - rt_off) /
> + sizeof(ext->rt[0]));
> down_write(&lgr->rmbs_lock);
> for (i = 0; i < max; i++) {
> smc_rtoken_set(lgr, link->link_idx, link_new->link_idx,
[Severity: High]
This isn't a bug introduced by this patch, but could this loop read
uninitialized or stale memory if a peer sends a truncated packet?
The loop in smc_llc_save_add_link_rkeys() calculates max based on the buffer
capacity (SMC_WR_BUF_V2_SIZE) instead of the actual received network length.
If a peer sends a short packet (e.g., 44 bytes) but specifies a large
num_rkeys in the header, could this read beyond the received data into stale
buffer memory, resulting in the host registering arbitrary memory regions?
[ ... ]
> @@ -1813,17 +1822,27 @@ static void smc_llc_rmt_delete_rkey(struct smc_link_group *lgr)
> link = qentry->link;
>
> if (lgr->smc_version == SMC_V2) {
> + const u32 rkey_off =
> + offsetof(struct smc_llc_msg_delete_rkey_v2, rkey);
> struct smc_llc_msg_delete_rkey_v2 *llcv2;
> + u32 buf_len;
>
> if (smc_link_shared_v2_rxbuf(link)) {
> memcpy(lgr->wr_rx_buf_v2, llc, sizeof(*llc));
[Severity: High]
This is a pre-existing issue, but does this memcpy() write to a buffer that
is actively mapped and exposed to the hardware?
Writing to lgr->wr_rx_buf_v2 (a DMA_FROM_DEVICE buffer) without unmapping or
syncing violates the DMA API. On non-cache-coherent architectures, dirtying
the cacheline here can cause conflicts when the cache is later invalidated to
read the hardware's data, which might destroy either the CPU's write or the
incoming hardware data.
> llcv2 = (struct smc_llc_msg_delete_rkey_v2 *)lgr->wr_rx_buf_v2;
> + buf_len = SMC_WR_BUF_V2_SIZE;
> } else {
> llcv2 = (struct smc_llc_msg_delete_rkey_v2 *)llc;
> + buf_len = sizeof(qentry->msg);
> }
[Severity: High]
Similar to the issue above, bounding buf_len to sizeof(qentry->msg) for
devices without a shared v2 receive buffer forces a limit of 44 bytes. Does
this silently truncate and ignore valid deletion requests from the sender when
the underlying single SGE actually received the full payload?
> llcv2->num_inval_rkeys = 0;
>
> max = min_t(u8, llcv2->num_rkeys, SMC_LLC_RKEYS_PER_MSG_V2);
> + /* the rkeys live in the buffer llcv2 points at, and nothing
> + * beyond it was received
> + */
> + max = min_t(u32, max, (buf_len - rkey_off) /
> + sizeof(llcv2->rkey[0]));
> for (i = 0; i < max; i++) {
> if (smc_rtoken_delete(link, llcv2->rkey[i]))
> llcv2->num_inval_rkeys++;
[Severity: High]
This is a pre-existing issue, but can this call to smc_rtoken_delete() cause
a data race?
It appears smc_llc_rmt_delete_rkey() calls smc_rtoken_delete() inside this
loop without holding lgr->rmbs_lock. Because smc_rtoken_delete() locklessly
modifies the shared lgr->rtokens array and the rtokens_used_mask bitmap,
could this race with concurrent modifications in smc_rtoken_add() and lead to
leaked rtokens or corrupted memory registrations?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260731070509.1818665-1-yhlee@isslab.korea.ac.kr?part=2
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH net v4 3/3] net/smc: carry oversized SMC-Rv2 LLC messages in the queue entry
2026-07-31 7:05 ` [PATCH net v4 3/3] net/smc: carry oversized SMC-Rv2 LLC messages in the queue entry Yehyeong Lee
@ 2026-08-01 7:05 ` sashiko-bot
0 siblings, 0 replies; 8+ messages in thread
From: sashiko-bot @ 2026-08-01 7:05 UTC (permalink / raw)
To: Yehyeong Lee; +Cc: Heiko Carstens, Vasily Gorbik, linux-s390, Alexander Gordeev
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] `num_rkeys` in `struct smc_llc_msg_add_link_v2_ext` is treated as a host-byte-order `u16`, causing interoperability failures between hosts of different endianness.
--
--- Patch [3]: [PATCH net v4 3/3] net/smc: carry oversized SMC-Rv2 LLC messages in the queue entry ---
commit 1b827af4505d8f9b89fd072971668e1eccaf6204
Author: Yehyeong Lee <yhlee@isslab.korea.ac.kr>
Subject: net/smc: carry oversized SMC-Rv2 LLC messages in the queue entry
This commit copies the tail of an oversized SMC-Rv2 LLC message into the queue
entry instead of relying on the receiver to reconstruct it from the shared v2
buffer. It bounds DELETE_RKEY_V2 processing based on the arrived message length
instead of the buffer size.
> diff --git a/net/smc/smc_llc.c b/net/smc/smc_llc.c
> index 606d2dc8c7ece..1b153173dd516 100644
> --- a/net/smc/smc_llc.c
> +++ b/net/smc/smc_llc.c
[ ... ]
> @@ -998,23 +1017,19 @@ static int smc_llc_cli_conf_link(struct smc_link *link,
>
> static void smc_llc_save_add_link_rkeys(struct smc_link *link,
> struct smc_link *link_new,
> - u8 *llc_msg)
> + struct smc_llc_qentry *qentry)
> {
> const u32 rt_off = offsetof(struct smc_llc_msg_add_link_v2_ext, rt);
> struct smc_llc_msg_add_link_v2_ext *ext;
> struct smc_link_group *lgr = link->lgr;
> int max, i;
>
> - /* The extension follows the 44 bytes of the LLC message. Without a
> - * shared v2 receive buffer nothing beyond those 44 bytes was received,
> - * so not even ext->num_rkeys is there to be read.
> - */
> - if (!smc_link_shared_v2_rxbuf(link))
> + /* the rkey count itself is only there if enough bytes arrived */
> + if (qentry->body_len < rt_off)
> return;
> - ext = (struct smc_llc_msg_add_link_v2_ext *)(llc_msg +
> - SMC_WR_TX_SIZE);
> + ext = (struct smc_llc_msg_add_link_v2_ext *)qentry->body;
> max = min_t(u8, ext->num_rkeys, SMC_LLC_RKEYS_PER_MSG_V2);
[Severity: High]
This is a pre-existing issue, but since this code is being modified, is it
safe to treat ext->num_rkeys as a host-byte-order u16 here?
If an x86 machine communicates with an s390x machine, smc_llc_fill_ext_v2()
writes lgr->conns_num into ext->num_rkeys in host byte order. A big-endian
receiver would read a value like 256.
When min_t() casts 256 to u8, wouldn't this truncate it to 0 and cause the
rkey exchange to fail on cross-endian links?
> - max = min_t(u32, max, (SMC_WR_BUF_V2_SIZE - SMC_WR_TX_SIZE - rt_off) /
> + max = min_t(u32, max, (qentry->body_len - rt_off) /
> sizeof(ext->rt[0]));
> down_write(&lgr->rmbs_lock);
> for (i = 0; i < max; i++) {
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260731070509.1818665-1-yhlee@isslab.korea.ac.kr?part=3
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH net v4 1/3] net/smc: fix use-after-free of the LLC qentry in smc_llc_srv_add_link()
2026-07-31 7:05 ` [PATCH net v4 1/3] net/smc: fix use-after-free of the LLC qentry in smc_llc_srv_add_link() Yehyeong Lee
@ 2026-08-01 7:05 ` sashiko-bot
0 siblings, 0 replies; 8+ messages in thread
From: sashiko-bot @ 2026-08-01 7:05 UTC (permalink / raw)
To: Yehyeong Lee; +Cc: Alexander Gordeev, Heiko Carstens, Vasily Gorbik, linux-s390
> smc_llc_srv_add_link() keeps add_llc pointing into the queue entry:
>
> add_llc = &qentry->msg.add_link; smc_llc.c:1482
> ...
> smc_llc_save_add_link_info(link_new, add_llc); smc_llc.c:1494
> smc_llc_flow_qentry_del(&lgr->llc_flow_lcl); smc_llc.c:1495
> ...
> u8 *llc_msg = smc_link_shared_v2_rxbuf(link) ?
> (u8 *)lgr->wr_rx_buf_v2 : (u8 *)add_llc; smc_llc.c:1504
> smc_llc_save_add_link_rkeys(link, link_new, llc_msg); smc_llc.c:1506
>
> smc_llc_flow_qentry_del() kfree()s the entry, so on a link without a shared
> v2 receive buffer the pointer handed to smc_llc_save_add_link_rkeys() is
> already freed. Before the Fixes: commit that branch always used
> lgr->wr_rx_buf_v2 and add_llc was not used after the free.
>
> Detach the entry instead of freeing it there, and free it explicitly on
> both exit paths. The reject path has to detach as well, otherwise it would
> be freed twice.
>
> Fixes: 27ef6a9981fe ("net/smc: support SMC-R V2 for rdma devices with max_recv_sge equals to 1")
> Cc: stable@vger.kernel.org
> Signed-off-by: Yehyeong Lee <yhlee@isslab.korea.ac.kr>
Sashiko has reviewed this patch and found no issues. It looks great!
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260731070509.1818665-1-yhlee@isslab.korea.ac.kr?part=1
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH net v4 2/3] net/smc: bound the peer rkey counts in SMC-Rv2 LLC messages
2026-08-01 7:05 ` sashiko-bot
@ 2026-08-01 9:10 ` Yehyeong Lee
0 siblings, 0 replies; 8+ messages in thread
From: Yehyeong Lee @ 2026-08-01 9:10 UTC (permalink / raw)
To: alibuda, dust.li, sidraya, wenjia, kuba, davem, edumazet, pabeni
Cc: Yehyeong Lee, sashiko-reviews, horms, mjambigi, tonylu, guwen,
guangguan.wang, kees, gustavoars, gor, hca, agordeev, netdev,
linux-rdma, linux-s390, linux-hardening, linux-kernel
sashiko-bot@kernel.org wrote:
> Does this early return cause a permanent protocol failure for devices
> with a single receive SGE?
The buffer part is right, but smc_llc_save_add_link_rkeys() does not
read that buffer. Without a shared v2 rxbuf its llc_msg argument is
&qentry->msg.add_link, and smc_llc_enqueue() copies only
sizeof(union smc_llc_msg) into the qentry -- 44 bytes, which is where
the extension starts. Same for the delete side.
I logged what smc_llc_fill_ext_v2() writes on the sender against what
smc_rtoken_set() gets on the receiver, over rxe with max_recv_sge
forced to 1. Unpatched, the sender wrote four distinct rkeys and the
receiver called smc_rtoken_set() 427 times, not once with one of them.
With 1/3 and 2/3 the path is not entered; with 3/3 as well it registers
six values, all the sender's.
So nothing is lost -- what mainline registers there is heap past a
72-byte kmalloc, which is the out-of-bounds 2/3 fixes.
The changelog is wrong to say "nothing beyond the 44 inline bytes was
received": it is received, it just never reaches the queue entry. I
will fix the wording in a v5.
Best regards,
Yehyeong Lee
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2026-08-01 9:12 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-07-31 7:05 [PATCH net v4 0/3] net/smc: fix out-of-bounds and use-after-free in SMC-Rv2 LLC processing Yehyeong Lee
2026-07-31 7:05 ` [PATCH net v4 1/3] net/smc: fix use-after-free of the LLC qentry in smc_llc_srv_add_link() Yehyeong Lee
2026-08-01 7:05 ` sashiko-bot
2026-07-31 7:05 ` [PATCH net v4 2/3] net/smc: bound the peer rkey counts in SMC-Rv2 LLC messages Yehyeong Lee
2026-08-01 7:05 ` sashiko-bot
2026-08-01 9:10 ` Yehyeong Lee
2026-07-31 7:05 ` [PATCH net v4 3/3] net/smc: carry oversized SMC-Rv2 LLC messages in the queue entry Yehyeong Lee
2026-08-01 7:05 ` sashiko-bot
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox