* [PATCH ipsec v2 1/1] xfrm: espintcp: do not reuse an in-progress partial send
@ 2026-06-02 16:46 Ren Wei
2026-06-09 6:12 ` Steffen Klassert
0 siblings, 1 reply; 2+ messages in thread
From: Ren Wei @ 2026-06-02 16:46 UTC (permalink / raw)
To: netdev
Cc: steffen.klassert, herbert, davem, sd, yuantan098, yifanwucs,
tomapufckgml, zcliangcn, bird, bronzed_45_vested, n05ec
From: Wyatt Feng <bronzed_45_vested@icloud•com>
espintcp keeps a single in-flight transmit in ctx->partial.
Before building a new sk_msg, espintcp_sendmsg() first tries to flush
that state through espintcp_push_msgs().
For blocking callers, espintcp_push_msgs() may return success even when
the previous partial send is still pending. espintcp_sendmsg() would
then reinitialize emsg->skmsg and reuse ctx->partial while the old
transfer still owns that state.
Do not rebuild the send message when ctx->partial is still in progress.
If espintcp_push_msgs() returns with emsg->len still set, fail the new
send instead of overwriting the live partial state.
This is a memory-safety fix: reusing the live partial-send state can
leave a stale offset attached to a new sk_msg and lead to an out-of-
bounds read in the send path.
tcp_sendmsg_locked() already handles waiting for send buffer memory, so
the fix here is just to preserve espintcp's one-message-at-a-time
transmit state.
Fixes: e27cca96cd68 ("xfrm: add espintcp (RFC 8229)")
Cc: stable@kernel•org
Reported-by: Yuan Tan <yuantan098@gmail•com>
Reported-by: Yifan Wu <yifanwucs@gmail•com>
Reported-by: Juefei Pu <tomapufckgml@gmail•com>
Reported-by: Zhengchuan Liang <zcliangcn@gmail•com>
Reported-by: Xin Liu <bird@lzu•edu.cn>
Assisted-by: Codex:GPT-5.4
Signed-off-by: Wyatt Feng <bronzed_45_vested@icloud•com>
Signed-off-by: Ren Wei <n05ec@lzu•edu.cn>
---
changes in v2:
- Drop the new wait loop in espintcp_sendmsg().
- Only reject reuse of ctx->partial if espintcp_push_msgs() leaves an
in-progress transfer behind.
- Reword the subject and changelog to match the narrowed fix.
- v1 Link: https://lore.kernel.org/all/b05daae0607621114d3818722a46c543ab6ec6fb.1780040524.git.bronzed_45_vested@icloud.com/
net/xfrm/espintcp.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/net/xfrm/espintcp.c b/net/xfrm/espintcp.c
index a2756186e13a..d9035546375e 100644
--- a/net/xfrm/espintcp.c
+++ b/net/xfrm/espintcp.c
@@ -346,6 +346,10 @@ static int espintcp_sendmsg(struct sock *sk, struct msghdr *msg, size_t size)
err = -ENOBUFS;
goto unlock;
}
+ if (emsg->len) {
+ err = -ENOBUFS;
+ goto unlock;
+ }
sk_msg_init(&emsg->skmsg);
while (1) {
--
2.43.7
^ permalink raw reply related [flat|nested] 2+ messages in thread
* Re: [PATCH ipsec v2 1/1] xfrm: espintcp: do not reuse an in-progress partial send
2026-06-02 16:46 [PATCH ipsec v2 1/1] xfrm: espintcp: do not reuse an in-progress partial send Ren Wei
@ 2026-06-09 6:12 ` Steffen Klassert
0 siblings, 0 replies; 2+ messages in thread
From: Steffen Klassert @ 2026-06-09 6:12 UTC (permalink / raw)
To: Ren Wei
Cc: netdev, herbert, davem, sd, yuantan098, yifanwucs, tomapufckgml,
zcliangcn, bird, bronzed_45_vested
On Wed, Jun 03, 2026 at 12:46:27AM +0800, Ren Wei wrote:
> From: Wyatt Feng <bronzed_45_vested@icloud•com>
>
> espintcp keeps a single in-flight transmit in ctx->partial.
> Before building a new sk_msg, espintcp_sendmsg() first tries to flush
> that state through espintcp_push_msgs().
>
> For blocking callers, espintcp_push_msgs() may return success even when
> the previous partial send is still pending. espintcp_sendmsg() would
> then reinitialize emsg->skmsg and reuse ctx->partial while the old
> transfer still owns that state.
>
> Do not rebuild the send message when ctx->partial is still in progress.
> If espintcp_push_msgs() returns with emsg->len still set, fail the new
> send instead of overwriting the live partial state.
>
> This is a memory-safety fix: reusing the live partial-send state can
> leave a stale offset attached to a new sk_msg and lead to an out-of-
> bounds read in the send path.
>
> tcp_sendmsg_locked() already handles waiting for send buffer memory, so
> the fix here is just to preserve espintcp's one-message-at-a-time
> transmit state.
>
> Fixes: e27cca96cd68 ("xfrm: add espintcp (RFC 8229)")
> Cc: stable@kernel•org
> Reported-by: Yuan Tan <yuantan098@gmail•com>
> Reported-by: Yifan Wu <yifanwucs@gmail•com>
> Reported-by: Juefei Pu <tomapufckgml@gmail•com>
> Reported-by: Zhengchuan Liang <zcliangcn@gmail•com>
> Reported-by: Xin Liu <bird@lzu•edu.cn>
> Assisted-by: Codex:GPT-5.4
> Signed-off-by: Wyatt Feng <bronzed_45_vested@icloud•com>
> Signed-off-by: Ren Wei <n05ec@lzu•edu.cn>
Patch appied, thanks a lot!
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2026-06-09 6:12 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-06-02 16:46 [PATCH ipsec v2 1/1] xfrm: espintcp: do not reuse an in-progress partial send Ren Wei
2026-06-09 6:12 ` Steffen Klassert
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox