Linux kernel NVMe-oF TCP host (nvme-tcp, digest error handling in io_work): The initiator kept reading from the socket

Impact

The initiator kept reading from the socket after deciding the TCP stream was already out of sync, producing a use-after-free on the compute node. This is the direction operators usually forget to threat-model: the storage target attacking its clients. A compromised or spoofed NVMe/TCP target - or anyone who can occupy that address on the storage network - gets kernel memory corruption on every GPU node that mounts from it, which is a fleet-wide blast radius from a single storage endpoint.

Who can reach it

Remote, from the target side. Requires being (or impersonating) the NVMe/TCP target the compute node connects to.

What to do

Kernel update on compute nodes bailing out of the io_work loop once the stream is known bad. Structurally: authenticate the target, not just the initiator - most clusters configure host-NQN allow lists in one direction only and leave the initiator trusting whatever answers on the storage IP.

References