Linux kernel (net/tls): When the crypto engine backlogs a kTLS encrypt request, both the async completion callback and

Impact

When the crypto engine backlogs a kTLS encrypt request, both the async completion callback and the synchronous error path clean up the same record. The double decrement corrupts the pending-operation sentinel, so the socket stops waiting for outstanding async encryptions entirely - a later send then frees the TLS record while the crypto callback is still holding it, and the callback fires on freed memory. Kernel heap use-after-free reachable by any process using kTLS, which on these nodes is the storage and control plane.

Who can reach it

Any local process that owns a socket and calls setsockopt(TLS_TX) - no privilege beyond owning the socket, so every tenant container has it - can drive this by pushing enough data to backlog the crypto engine. Loading the fleet's crypto queue is easy for a co-tenant, and the CNA scores it network-reachable because a peer that drives sustained TLS traffic contributes to the same backlog condition. No device node and no CAP_NET_ADMIN required.

What to do

Update to 5.15.203 / 6.1.169 / 6.6.135 / 6.8 or later. Interim control: there is no clean one - kTLS is attachable by any socket owner. If a fleet cannot be rebooted promptly, disabling the kTLS ULP (blacklist tls) removes the reachable path at the cost of falling back to userspace TLS.

References