Linux kernel nvmet-tcp - PDU iovec construction and H2C Transfer Tag handling: nvmet_tcp_build_pdu_iovec() walks past

Impact

nvmet_tcp_build_pdu_iovec() walks past the command's scatterlist when a PDU length or offset exceeds sg_cnt and then builds a bvec from garbage sg->length/offset values, and in the related defect the error is not propagated so the socket receive loop reads network data into an uninitialised iterator. The older sibling is the same shape: the Transfer Tag in an H2C_DATA PDU is used as an array index with no bounds check. All three give an initiator on the storage network control over where the target kernel copies received data - memory corruption in the process that owns every tenant's namespace mappings, and a straightforward crash of the entire target if you only want the outage.

Who can reach it

Any host that can complete an NVMe/TCP connection to the target on TCP 4420 and send a malformed PDU. A provisioned namespace is not required for the connection-level PDU handling; on a fabric with no in-band auth, any host on the storage VLAN qualifies.

What to do

Kernel update on target nodes, reboot, arrays offline for the duration unless you can fail initiators to a peer target first. There is no runtime workaround - the parsing happens before any policy check. Between now and the maintenance window, the storage VLAN ACL is the control: only known initiator IPs reach 4420. Note the 2022 Transfer Tag bounds check applies to long-lived kernels many operators are still running under distro LTS, so check your actual kernel rather than assuming a recent distro release covers it.

References