The call to nvme_free_sgls() in nvme_unmap_data() has the sg_list and sge
parameters swapped.  This wasn't noticed by the compiler because both share
the same type.  On a Xen PV hardware domain, and possibly any other
architectures that takes that path, this leads to corruption of the NVMe
contents.

Fixes: f0887e2a52d4 ("nvme-pci: create common sgl unmapping helper")
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
---
If possible it would be good for this to go in 6.19.0-rc8, as corruption of
the root device as part of a kernel update is unexpected. Sadly 6.18
already contained this issue, and no-one noticed, so its impact is limited?
---
 drivers/nvme/host/pci.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c
index 0e4caeab739c..c8c5ed3eeac7 100644
--- a/drivers/nvme/host/pci.c
+++ b/drivers/nvme/host/pci.c
@@ -806,8 +806,8 @@ static void nvme_unmap_data(struct request *req)
 	if (!blk_rq_dma_unmap(req, dma_dev, &iod->dma_state, iod->total_len,
 			      map)) {
 		if (nvme_pci_cmd_use_sgl(&iod->cmd))
-			nvme_free_sgls(req, iod->descriptors[0],
-				       &iod->cmd.common.dptr.sgl, attrs);
+			nvme_free_sgls(req, &iod->cmd.common.dptr.sgl,
+			               iod->descriptors[0], attrs);
 		else
 			nvme_free_prps(req, attrs);
 	}
-- 
2.51.0

On Tue, Jan 27, 2026 at 08:59:06PM +0100, Roger Pau Monne wrote:
> The call to nvme_free_sgls() in nvme_unmap_data() has the sg_list and sge
> parameters swapped.  This wasn't noticed by the compiler because both share
> the same type.  On a Xen PV hardware domain, and possibly any other
> architectures that takes that path, this leads to corruption of the NVMe
> contents.

Thanks, applied to nvme-6.19 with updated subject.

On Tue, Jan 27, 2026 at 08:59:06PM +0100, Roger Pau Monne wrote:
> The call to nvme_free_sgls() in nvme_unmap_data() has the sg_list and sge
> parameters swapped.  This wasn't noticed by the compiler because both share
> the same type.  On a Xen PV hardware domain, and possibly any other
> architectures that takes that path, this leads to corruption of the NVMe
> contents.
> 
> Fixes: f0887e2a52d4 ("nvme-pci: create common sgl unmapping helper")
> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
> ---
> If possible it would be good for this to go in 6.19.0-rc8, as corruption of
> the root device as part of a kernel update is unexpected. Sadly 6.18
> already contained this issue, and no-one noticed, so its impact is limited?

This only affects non-IOMMU paths with a non-noop dma_unmap_phys.
So it is a very common setup, but very severe for those.  Because of
that we should get into 6.19-rc and -stable ASAP.

The fix looks good:

Reviewed-by: Christoph Hellwig <hch@lst.de>

but maybe we can reword the subject to sound less harmless, e.g.:

nvme-pci: DMA unmap the correct regions in nvme_free_sgls

?

On Wed, Jan 28, 2026 at 09:49:58AM +0100, Christoph Hellwig wrote:
> On Tue, Jan 27, 2026 at 08:59:06PM +0100, Roger Pau Monne wrote:
> > The call to nvme_free_sgls() in nvme_unmap_data() has the sg_list and sge
> > parameters swapped.  This wasn't noticed by the compiler because both share
> > the same type.  On a Xen PV hardware domain, and possibly any other
> > architectures that takes that path, this leads to corruption of the NVMe
> > contents.
> > 
> > Fixes: f0887e2a52d4 ("nvme-pci: create common sgl unmapping helper")
> > Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
> > ---
> > If possible it would be good for this to go in 6.19.0-rc8, as corruption of
> > the root device as part of a kernel update is unexpected. Sadly 6.18
> > already contained this issue, and no-one noticed, so its impact is limited?
> 
> This only affects non-IOMMU paths with a non-noop dma_unmap_phys.
> So it is a very common setup, but very severe for those.  Because of

Do you mean a "not very common setup"?  Otherwise I can't parse the
sentence.

> that we should get into 6.19-rc and -stable ASAP.
> 
> The fix looks good:
> 
> Reviewed-by: Christoph Hellwig <hch@lst.de>

Thanks.

> but maybe we can reword the subject to sound less harmless, e.g.:
> 
> nvme-pci: DMA unmap the correct regions in nvme_free_sgls

Fine with me.  I think I was more focused on describing the logical
change rather that the actual effect of it.  Can you adjust it when
picking up?

Regards, Roger.

On Wed, Jan 28, 2026 at 10:10:08AM +0100, Roger Pau Monné wrote:
> > > the root device as part of a kernel update is unexpected. Sadly 6.18
> > > already contained this issue, and no-one noticed, so its impact is limited?
> > 
> > This only affects non-IOMMU paths with a non-noop dma_unmap_phys.
> > So it is a very common setup, but very severe for those.  Because of
> 
> Do you mean a "not very common setup"?  Otherwise I can't parse the
> sentence.

Yes, sorry.