From: Andrea Parri <parri.andrea@gmail.com>
To: Christoph Hellwig <hch@lst.de>, Sagi Grimberg <sagi@grimberg.me>,
Chaitanya Kulkarni <kch@nvidia.com>
Cc: "Andrea Parri" <parri.andrea@gmail.com>,
"Damien Le Moal" <dlemoal@kernel.org>,
"Keith Busch" <kbusch@kernel.org>,
"Manivannan Sadhasivam" <mani@kernel.org>,
"Krzysztof Wilczyński" <kwilczynski@kernel.org>,
"Niklas Cassel" <cassel@kernel.org>,
linux-nvme@lists.infradead.org, linux-kernel@vger.kernel.org,
stable@vger.kernel.org
Subject: [PATCH v2 4/4] nvmet: pci-epf: require SGLs to match the command data length
Date: Thu, 22 Oct 2026 15:29:33 +0200 [thread overview]
Message-ID: <20261022132934.3592924-5-parri.andrea@gmail.com> (raw)
In-Reply-To: <20261022132934.3592924-1-parri.andrea@gmail.com>
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.
Fixes: 0faa0fe6f90e ("nvmet: New NVMe PCI endpoint function target driver")
Cc: stable@vger.kernel.org
Tested-by: Niklas Cassel <cassel@kernel.org>
Signed-off-by: Andrea Parri <parri.andrea@gmail.com>
---
For stable, this depends on patch 3/4: without it, the new Data SGL
Length Invalid error is still reported to the host as a success.
drivers/nvme/target/pci-epf.c | 29 +++++++++++++++++++++++++++--
1 file changed, 27 insertions(+), 2 deletions(-)
diff --git a/drivers/nvme/target/pci-epf.c b/drivers/nvme/target/pci-epf.c
index 099e8766f6d40..0cc198f87dec3 100644
--- a/drivers/nvme/target/pci-epf.c
+++ b/drivers/nvme/target/pci-epf.c
@@ -1070,10 +1070,22 @@ static int nvmet_pci_epf_iod_parse_sgl_segments(struct nvmet_pci_epf_ctrl *ctrl,
return 0;
}
+static u64 nvmet_pci_epf_iod_data_segs_len(struct nvmet_pci_epf_iod *iod)
+{
+ u64 len = 0;
+ int i;
+
+ for (i = 0; i < iod->nr_data_segs; i++)
+ len += iod->data_segs[i].length;
+
+ return len;
+}
+
static int nvmet_pci_epf_iod_parse_sgls(struct nvmet_pci_epf_iod *iod)
{
struct nvmet_pci_epf_ctrl *ctrl = iod->ctrl;
struct nvme_sgl_desc *sgl = &iod->cmd.common.dptr.sgl;
+ int ret;
if (sgl->type == (NVME_SGL_FMT_DATA_DESC << 4)) {
/* Single data descriptor case. */
@@ -1081,10 +1093,23 @@ static int nvmet_pci_epf_iod_parse_sgls(struct nvmet_pci_epf_iod *iod)
iod->data_segs = &iod->data_seg;
iod->data_seg.pci_addr = le64_to_cpu(sgl->addr);
iod->data_seg.length = le32_to_cpu(sgl->length);
- return 0;
+ } else {
+ ret = nvmet_pci_epf_iod_parse_sgl_segments(ctrl, iod);
+ if (ret)
+ return ret;
}
- return nvmet_pci_epf_iod_parse_sgl_segments(ctrl, iod);
+ /*
+ * The command executes on data_len bytes, but each segment is
+ * allocated and transferred in full, so they must describe exactly
+ * data_len bytes.
+ */
+ if (nvmet_pci_epf_iod_data_segs_len(iod) != iod->data_len) {
+ iod->status = NVME_SC_SGL_INVALID_DATA | NVME_STATUS_DNR;
+ return -EINVAL;
+ }
+
+ return 0;
}
static int nvmet_pci_epf_alloc_iod_data_buf(struct nvmet_pci_epf_iod *iod)
--
2.53.0
next prev parent reply other threads:[~2026-10-22 13:30 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-22 13:29 [PATCH v2 0/4] nvmet: fix read data, status and length checks in fc, zns and pci-epf Andrea Parri
2026-10-22 13:29 ` [PATCH v2 1/4] nvmet-fc: only send read data for successful commands Andrea Parri
2026-10-22 13:29 ` [PATCH v2 2/4] nvmet: zns: reject a NUMD whose byte count wraps Andrea Parri
2026-10-22 13:29 ` [PATCH v2 3/4] nvmet: pci-epf: report transport errors in command completions Andrea Parri
2026-10-22 13:29 ` Andrea Parri [this message]
2026-10-22 15:16 ` [PATCH v2 0/4] nvmet: fix read data, status and length checks in fc, zns and pci-epf Keith Busch
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=20261022132934.3592924-5-parri.andrea@gmail.com \
--to=parri.andrea@gmail.com \
--cc=cassel@kernel.org \
--cc=dlemoal@kernel.org \
--cc=hch@lst.de \
--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=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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®