Re: [PATCH v2 0/4] nvmet: fix read data, status and length checks in fc, zns and pci-epf

[Keith Busch]

On Thu, Oct 22, 2026 at 03:29:29PM +0200, Andrea Parri wrote:
> A connected host can currently receive stale target memory through two
> nvmet transports, and ZNS answers a Zone Management Receive whose NUMD
> byte count wraps.
> 
> The FC transport sends a read buffer even when the command completes with
> an error.  Some errors occur before the command handler initializes that
> buffer, so the host receives data left in the allocation.
> 
> The PCI endpoint transport allocates each read segment at the length of
> the host's SGL data descriptor and sends every segment in full, even when
> the descriptors describe more than the command transfers.  The excess
> reaches the host uninitialized, on any successful read.
> 
> Patch 1 makes the FC transport send read data only for successful
> commands, matching the TCP and RDMA transports.  Patch 2 rejects NUMD
> values whose byte count wraps the u32 length calculation instead of
> accepting the wrapped request.
> 
> Patch 3 fixes a related PCI endpoint bug that patch 4 depends on.  The
> transport reports every error it detects itself as a successful
> completion, because nvmet_pci_epf_complete_iod() reloads the status from
> a CQE that only the nvmet core fills in, so even a write whose data
> could not be fetched is reported as written.  Patch 4 then makes the
> transport reject SGLs whose data descriptors do not add up to the
> command's data length.
> 
> Patches 1 and 2 were tested on top of nvme-7.4 over the loop, tcp, rdma
> (rdma_rxe) and fc (fcloop) transports, with a zoned null_blk namespace
> for patch 2.  Without them, a failed Identify over fc returns data and a
> wrapping NUMD is accepted; with them, neither occurs on any of the four
> transports.

Looks good to me. Applied to nvme-7.4.