Linux kernel (net/tls): The queue that pins encrypted input buffers while the AEAD engine still references them was

Impact

The queue that pins encrypted input buffers while the AEAD engine still references them was only drained from one caller. If the hold operation fails part-way - after some cloned buffers are already queued - those clones are never released, because the drain only runs when a record completed in fully-async mode. Sustained TLS receive traffic under memory pressure therefore leaks kernel socket buffers steadily, and on a shared node that ends in host memory exhaustion rather than a per-connection problem.

Who can reach it

A remote TLS peer feeding records to a kTLS receive socket, with no credentials required - the failure that starts the leak is an allocation failure inside the hold path, which the peer can encourage by driving high record rates and which a co-tenant can supply directly by putting the node under memory pressure. Every tenant container can attach kTLS receive with setsockopt(TLS_RX), so the reachable surface is any TLS connection terminated in-kernel on the node.

What to do

Update to 6.1.168 / 6.6.131 / 6.12.80 / 6.18 or later. Interim control: monitor skbuff slab growth on nodes terminating kTLS, keep memory headroom so the hold path does not fail, and blacklist the tls ULP if a node cannot be rebooted and is already showing unexplained skb growth.

References