Linux kernel (net/tls): Closing a kTLS socket cancelled the transmit work item, but the write-space callback could

Impact

Closing a kTLS socket cancelled the transmit work item, but the write-space callback could re-schedule it immediately afterwards from softirq. The worker then runs against a freed TLS context - a use-after-free on socket teardown that a remote peer helps time, since the re-schedule comes from the delayed-ACK path. Kernel heap corruption reachable by any tenant that uses kTLS, with the timing supplied by the far end of the connection.

Who can reach it

Any local process that attaches kTLS to a socket (setsockopt TLS_TX - no special privilege, available to every tenant container) and closes it while data is still in flight. The re-schedule window is opened by the peer's ACK behaviour, so a cooperating or hostile remote endpoint on the fabric can widen it deliberately by controlling when it acknowledges. No device node, no CAP_NET_ADMIN.

What to do

Boot a kernel carrying the fix commits below (no fixed stable version published in the record). Interim control: none that preserves kTLS - the only real lever is blacklisting the tls ULP module so tenants fall back to userspace TLS until the fleet is rebooted.

References