Linux kernel (net/xfrm): Closing an ESP-in-TCP socket cancels its transmit work item, but the write-space callback can

Impact

Closing an ESP-in-TCP socket cancels its transmit work item, but the write-space callback can re-schedule that work from softirq immediately afterwards. The worker then runs against a freed espintcp context or a freed socket - a use-after-free on teardown whose timing is supplied by the peer's acknowledgement behaviour. Same defect shape as the kTLS one in CVE-2026-23240, in the IPsec-over-TCP path.

Who can reach it

A local process that attaches the espintcp ULP to a TCP socket (no privilege beyond owning the socket) and closes it with data still in flight. The re-schedule comes from the delayed-ACK handler or ksoftirqd, so a remote peer on the fabric can widen the window by controlling when it acknowledges. Conditional on CONFIG_INET_ESPINTCP. Found by source audit.

What to do

Boot a kernel carrying the fix commits below (no fixed stable version published). Interim control: disable CONFIG_INET_ESPINTCP on nodes that do not need IPsec-over-TCP so the ULP cannot be attached.

References