PT-2026-51728 · Linux · Linux
Published
2026-06-24
·
Updated
2026-06-24
·
CVE-2026-52935
None
No severity ratings or metrics are available. When they are, we'll update the corresponding info on the page.
In the Linux kernel, the following vulnerability has been resolved:
xfrm: espintcp: do not reuse an in-progress partial send
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.
Found an issue in the description? Have something to add? Feel free to write us 👾
Related Identifiers
Affected Products
Linux