Linux kernel (net/tls): A BPF verdict that grows the scatterlist (bpf_msg_push_data) combined with a cork_bytes setting

Impact

A BPF verdict that grows the scatterlist (bpf_msg_push_data) combined with a cork_bytes setting makes kTLS roll back to the non-zerocopy path with a reset msg_iter but an already-grown sg.size. The revert walks past the end of the iterator and hits a hard BUG() in iov_iter_revert - an immediate kernel panic on a shared node.

Who can reach it

Needs a sockmap/sk_msg BPF program with cork_bytes set attached to a kTLS TX socket, then any sendmsg/sendto on that socket. Attaching needs CAP_BPF (CNI, service-mesh sidecar, or a tenant granted BPF); once attached, ordinary tenant sends trigger the panic. Not reachable from a plain unprivileged container with no BPF access.

What to do

Boot a kernel carrying the linked stable commits. Interim: do not grant CAP_BPF to tenant containers, and remove sk_msg programs that push data on corked kTLS sockets.

References

Related entries

• Linux kernel (net/tls): KTLS assumes it owns the TCP receive queue. When another reader drains bytes first, the oldCVE-2025-38616 · Linux kernel (net/tls)High
• Linux kernel (net/tls): The kTLS device-offload setup resolved the socket's netdevice outside RCU, so the net_device itCVE-2025-40149 · Linux kernel (net/tls)High
• Linux kernel (net/tls): A receiver that holds its TCP window at zero keeps the kTLS sender blocked inside tx_lockCVE-2023-54306 · Linux kernel (net/tls)High
• Linux kernel (net/tls): If a page allocation fails while the TLS strparser is copying a partial record, the receiveCVE-2025-38018 · Linux kernel (net/tls)High
• Linux kernel (net/tls): The queue that pins encrypted input buffers while the AEAD engine still references them wasCVE-2026-23414 · Linux kernel (net/tls)High
• Linux kernel (net/tls): When kTLS RX offload fails at tls_dev_add, the rollback frees the software context but neverCVE-2026-52974 · Linux kernel (net/tls)High