From: Wyatt Feng 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 Reported-by: Yifan Wu Reported-by: Juefei Pu Reported-by: Zhengchuan Liang Reported-by: Xin Liu Assisted-by: Codex:GPT-5.4 Signed-off-by: Wyatt Feng Signed-off-by: Ren Wei --- 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