Linux kernel (net/tls): When kTLS RX offload fails at tls_dev_add, the rollback frees the software context but never

Impact

When kTLS RX offload fails at tls_dev_add, the rollback frees the software context but never frees the strparser anchor skb allocated during init. Every failed offload attempt leaks an skb, so a tenant that loops failing setsockopt calls bleeds kernel memory until the node starts OOM-killing other tenants' workloads.

Who can reach it

Local and unprivileged, no device node: setsockopt(SOL_TLS, TLS_RX) on a socket bound to a NIC that advertises kTLS RX offload but rejects the add - which happens once the NIC's offload contexts are exhausted, a state the same tenant can create. Only affects nodes with kTLS RX offload-capable NICs (ConnectX-class), which is exactly the storage-path configuration in these fleets.

What to do

Boot a kernel carrying the linked stable commits. Interim: disable kTLS RX hardware offload (ethtool -K <dev> tls-hw-rx-offload off) so the failing add path is never taken, and cap per-tenant memory.

References