Linux kernel (net/tls): KTLS stored a negative errno into the socket error field where a positive value is expected. A

Impact

KTLS stored a negative errno into the socket error field where a positive value is expected. A splice or sendfile consumer reads it back and negates it, so an error is interpreted as a positive count of bytes written. The pipe buffer length and the descriptor length both underflow, producing an enormous buffer offset and bogus addresses passed to the copy actor - memory corruption in a shared code path, triggered by nothing more than a TLS crypto request failing.

Who can reach it

Any unprivileged local process using kTLS with splice/sendfile-style zero-copy transmission - available to every tenant container, since kTLS needs no capability. The trigger is an encrypt request returning an error, which a tenant can precipitate by saturating the crypto engine or by using a crypto backend under memory pressure; a co-tenant supplying that pressure works just as well. No device node, no fabric peer required, though a peer driving the connection helps keep the splice loop active.

What to do

Boot a kernel carrying the fix commits below (no fixed stable version published). This one is old enough that most maintained kernels already carry it - verify by commit rather than assume, particularly on long-lived vendor kernels. Interim control: avoid splice/sendfile on kTLS sockets, or blacklist the tls ULP.

References