Linux kernel (net/tls): A particular kTLS ring state builds a scatterlist whose chain link points directly at another

Impact

A particular kTLS ring state builds a scatterlist whose chain link points directly at another chain link. The scatterlist iterator does not resolve chained links recursively, so this is illegal input to the crypto API - the AEAD walk runs off into whatever the second link descriptor happens to be. The practical outcome is the crypto engine reading and writing memory outside the record's buffers during TLS encryption, on the same code path that carries storage and control traffic.

Who can reach it

Any unprivileged local process that enables kTLS on its socket with setsockopt(TLS_TX) and drives the send ring into the wrapped state (ring end at zero with a non-zero start). Every tenant container can do this - kTLS attachment needs no capability. TLS 1.3 records make the condition easier to hit because they consume the reserved wrap slot for content-type chaining.

What to do

Boot a kernel carrying the fix commits below - the record's version field (5.5) is the introducing release, not a fix. Interim control: blacklist the tls ULP module so tenants cannot attach kTLS, at the cost of userspace TLS performance.

References