[PATCH 5/5] nvmet: pci-epf: require SGLs to match the command data length
Niklas Cassel
cassel at kernel.org
Wed Oct 14 05:47:11 PDT 2026
On Tue, Oct 13, 2026 at 04:28:30PM +0200, Christoph Hellwig wrote:
> On Mon, Oct 12, 2026 at 04:12:32PM +0200, Andrea Parri wrote:
> > The PCI endpoint target sends the host every byte a read command's SGL
> > describes, even when the SGL describes more than the command transfers.
> > The excess is kmalloc() memory the command never wrote, so the host
> > receives stale target memory. Any successful read can do this,
> > including Identify.
> >
> > nvmet_pci_epf_alloc_iod_data_buf() allocates each segment at the length
> > of its SGL data descriptor, but sets req->transfer_len from
> > iod->data_len, the length the command implies. Once the command
> > completes, nvmet_pci_epf_transfer_iod_data() sends every segment in
> > full. Nothing compares the descriptor lengths with iod->data_len, and
> > the MDTS check only bounds iod->data_len.
> >
> > Fail the command with Data SGL Length Invalid when the data descriptors
> > do not add up to iod->data_len, before any segment is allocated. The
> > tcp and rdma transports take the data length from the SGL itself, so
> > there most commands already reject a mismatch in
> > nvmet_check_transfer_len(). PRP lists are built from iod->data_len and
> > are unaffected.
> >
> > Found by code inspection. Build-tested only (x86_64, W=1): no PCI
> > endpoint hardware was available to run it.
>
> Looks good, although again having this validated on hardware would
> be really useful.
>
Tested-by: Niklas Cassel <cassel at kernel.org>
More information about the Linux-nvme
mailing list