Linux kernel (net/xfrm): ESP-in-TCP keeps a single in-flight transmit. For a blocking caller the flush of that state

Impact

ESP-in-TCP keeps a single in-flight transmit. For a blocking caller the flush of that state can report success while the previous partial send is still live, so the socket rebuilds its scatter-gather message over state the old transfer still owns. Upstream calls this a memory-safety fix explicitly: a stale offset carried into a fresh message produces an out-of-bounds read on the send path, leaking adjacent kernel memory into the encrypted stream or faulting.

Who can reach it

A local process that attaches the espintcp ULP to a TCP socket - setsockopt(TCP_ULP, "espintcp"), which needs nothing beyond owning the socket, so any unprivileged tenant process qualifies - and then issues blocking sendmsg calls that only partially complete. Partial completion is easy to force by shrinking the send buffer or by having a slow peer. Conditional on CONFIG_INET_ESPINTCP being enabled in the kernel, which it is in most distro builds.

What to do

Boot a kernel carrying the fix commits below (no fixed stable version published). Interim control: build or ship kernels without CONFIG_INET_ESPINTCP where IPsec-over-TCP is not needed, which removes the ULP entirely.

References