From: Christoph Hellwig <hch@lst.de>
To: Andrea Parri <parri.andrea@gmail.com>
Cc: "Christoph Hellwig" <hch@lst.de>,
"Sagi Grimberg" <sagi@grimberg.me>,
"Chaitanya Kulkarni" <kch@nvidia.com>,
"Damien Le Moal" <dlemoal@kernel.org>,
"Niklas Cassel" <cassel@kernel.org>,
"Keith Busch" <kbusch@kernel.org>,
"Manivannan Sadhasivam" <mani@kernel.org>,
"Krzysztof Wilczyński" <kwilczynski@kernel.org>,
linux-nvme@lists.infradead.org, linux-kernel@vger.kernel.org,
stable@vger.kernel.org
Subject: Re: [PATCH 5/5] nvmet: pci-epf: require SGLs to match the command data length
Date: Tue, 13 Oct 2026 16:28:30 +0200 [thread overview]
Message-ID: <20261013142830.GF14759@lst.de> (raw)
In-Reply-To: <20261012141239.156408-6-parri.andrea@gmail.com>
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.
prev parent reply other threads:[~2026-10-13 14:28 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-12 14:12 [PATCH 0/5] nvmet: fix stale data exposure and ZNS validation Andrea Parri
2026-10-12 14:12 ` [PATCH 1/5] nvmet-fc: only send read data for successful commands Andrea Parri
2026-10-12 14:12 ` [PATCH 2/5] nvmet: zns: don't leak stale memory in zone management receive Andrea Parri
2026-10-13 14:25 ` Christoph Hellwig
2026-10-13 15:47 ` Keith Busch
2026-10-12 14:12 ` [PATCH 3/5] nvmet: zns: reject a NUMD whose byte count wraps Andrea Parri
2026-10-13 14:26 ` Christoph Hellwig
2026-10-12 14:12 ` [PATCH 4/5] nvmet: pci-epf: report transport errors in command completions Andrea Parri
2026-10-13 14:27 ` Christoph Hellwig
2026-10-13 15:12 ` Damien Le Moal
2026-10-12 14:12 ` [PATCH 5/5] nvmet: pci-epf: require SGLs to match the command data length Andrea Parri
2026-10-13 14:28 ` Christoph Hellwig [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20261013142830.GF14759@lst.de \
--to=hch@lst.de \
--cc=cassel@kernel.org \
--cc=dlemoal@kernel.org \
--cc=kbusch@kernel.org \
--cc=kch@nvidia.com \
--cc=kwilczynski@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=mani@kernel.org \
--cc=parri.andrea@gmail.com \
--cc=sagi@grimberg.me \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.