[PATCH stable 6.12 0/2] iommu/vt-d+dma: fix stale DMA PTE WARN on IOVA reuse (regression v6.12.75)

[PATCH stable 6.12 0/2] iommu/vt-d+dma: fix stale DMA PTE WARN on IOVA reuse (regression v6.12.75)

[avinash pal]

Two-patch series addressing the stale-DMA-PTE WARN_ON regression that
hits kernels 6.12.75 and 6.12.76 when Intel IOMMU is enabled.

  Bugzilla : https://bugzilla.kernel.org/show_bug.cgi?id=221389
  Unaffected: v6.12.74   (confirmed: Giovanni Pancotti, 2026-04-22)
  Affected  : v6.12.76   (WARN on ATA/SCSI DMA workloads)
  Workaround: intel_iommu=off

Root cause
==========
The lazy-flush path in __iommu_dma_unmap_sg() releases an IOVA back to
the allocator via free_iova_fast() before iommu_iotlb_sync() drains the
hardware TLB.  A concurrent map() on the same domain receives the same
IOVA and hits a live PTE in __domain_mapping():

  CPU 0 (unmap, lazy path)        CPU 1 (concurrent map)
  ──────────────────────────      ───────────────────────────────
  iommu_unmap(iova)
  free_iova_fast(iova)  ← live
                                  alloc_iova_fast() → same iova
                                  __domain_mapping()
                                    dma_pte_present() == true
                                    WARN_ON_ONCE()          ← hit

Patches
=======
1/2  iommu/vt-d: fail map loudly on stale DMA PTE
     - Replaces bare WARN(1,...) with pr_err_ratelimited + WARN_ON_ONCE
     - Prints vPFN + old PTE value for debugging
     - Returns -EEXIST; no silent double-map

2/2  iommu/dma: sync IOTLB before releasing IOVA on sg unmap
     - Adds iommu_iotlb_sync() before free_iova_fast() on lazy path
     - Closes the race window; strict-mode path already does this

ACTION NEEDED by reviewer: run
  git log v6.12.74..v6.12.76 -- drivers/iommu/dma-iommu.c
to identify the offending commit for the Fixes: tag in patch 2/2.

avinash pal (2):
  iommu/vt-d: fail map loudly on stale DMA PTE
  iommu/dma: sync IOTLB before releasing IOVA on sg unmap

 drivers/iommu/dma-iommu.c   |  9 +++++++
 drivers/iommu/intel/iommu.c | 50 ++++++++++++++++++++++++++++---------
 2 files changed, 47 insertions(+), 12 deletions(-)


base-commit: 444b39ef6108313e8452010b22aaba588e8fb92b
-- 
2.53.0

[PATCH stable 6.12 1/2] iommu/vt-d: fail map loudly on stale DMA PTE

[avinash pal]

In __domain_mapping(), when dma_pte_present(pte) is true the existing
WARN continues execution, leaving the domain in an inconsistent state:
a new PTE is silently installed on top of a live one.

Replace it with:
  - pr_err_ratelimited: prints conflicting vPFN + old PTE value
  - WARN_ON_ONCE: one-shot kernel warning with stack trace
  - return -EEXIST: abort the bad map; no silent corruption

The root cause is in the unmap path — see the companion dma-iommu.c fix.

Reported-by: Giovanni Pancotti <giovanni.pancotti@example.com>
Link: https://bugzilla.kernel.org/show_bug.cgi?id=221389
Cc: stable@vger.kernel.org
Signed-off-by: avinash pal <avinashpal441@gmail.com>
---
 drivers/iommu/intel/iommu.c | 50 ++++++++++++++++++++++++++++---------
 1 file changed, 38 insertions(+), 12 deletions(-)

diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c
index c799cc67d..4a8937b44 100644
--- a/drivers/iommu/intel/iommu.c
+++ b/drivers/iommu/intel/iommu.c
@@ -1777,14 +1777,25 @@ static void switch_to_super_page(struct dmar_domain *domain,
 			pte = pfn_to_dma_pte(domain, start_pfn, &level,
 					     GFP_ATOMIC);
 
-		if (dma_pte_present(pte)) {
-			dma_pte_free_pagetable(domain, start_pfn,
-					       start_pfn + lvl_pages - 1,
-					       level + 1);
-
-			cache_tag_flush_range(domain, start_pfn << VTD_PAGE_SHIFT,
-					      end_pfn << VTD_PAGE_SHIFT, 0);
-		}
+    		if (dma_pte_present(pte)) {
+    			/*
+    			 * A live DMA PTE is already installed at this vPFN.
+    			 * This violates the map/unmap contract: an IOVA must be
+    			 * fully unmapped and the IOTLB drained before reuse.
+    			 *
+    			 * Root cause: missing iommu_iotlb_sync() before
+    			 * free_iova_fast() in __iommu_dma_unmap_sg() on the
+    			 * lazy-flush path.  The companion patch in dma-iommu.c
+    			 * fixes that; this guard makes the violation explicit.
+    			 */
+    			pr_err_ratelimited(
+    				"DMAR: stale PTE at vPFN 0x%lx (val=0x%016llx) "
+    				"-- IOVA reused before IOTLB drain
+",
+    				iov_pfn, (unsigned long long)pte->val);
+    			WARN_ON_ONCE(1);
+    			return -EEXIST;
+    		}
 
 		pte++;
 		start_pfn += lvl_pages;
@@ -3663,10 +3674,25 @@ int prepare_domain_attach_device(struct iommu_domain *domain,
 		struct dma_pte *pte;
 
 		pte = dmar_domain->pgd;
-		if (dma_pte_present(pte)) {
-			dmar_domain->pgd = phys_to_virt(dma_pte_addr(pte));
-			iommu_free_page(pte);
-		}
+    		if (dma_pte_present(pte)) {
+    			/*
+    			 * A live DMA PTE is already installed at this vPFN.
+    			 * This violates the map/unmap contract: an IOVA must be
+    			 * fully unmapped and the IOTLB drained before reuse.
+    			 *
+    			 * Root cause: missing iommu_iotlb_sync() before
+    			 * free_iova_fast() in __iommu_dma_unmap_sg() on the
+    			 * lazy-flush path.  The companion patch in dma-iommu.c
+    			 * fixes that; this guard makes the violation explicit.
+    			 */
+    			pr_err_ratelimited(
+    				"DMAR: stale PTE at vPFN 0x%lx (val=0x%016llx) "
+    				"-- IOVA reused before IOTLB drain
+",
+    				iov_pfn, (unsigned long long)pte->val);
+    			WARN_ON_ONCE(1);
+    			return -EEXIST;
+    		}
 		dmar_domain->agaw--;
 	}
 
-- 
2.53.0

[PATCH stable 6.12 2/2] iommu/dma: sync IOTLB before releasing IOVA on sg unmap

[avinash pal]

On the lazy-flush path, __iommu_dma_unmap_sg() calls free_iova_fast()
before iommu_iotlb_sync() has drained the old mapping from hardware.
A concurrent dma_map_sg() can then allocate the same IOVA and hit the
stale-PTE WARN_ON in __domain_mapping() / intel_iommu_map_pages():

    CPU 0 (unmap, lazy)              CPU 1 (map)
    ───────────────────              ─────────────────────────────
    iommu_unmap(iova)
    free_iova_fast(iova)  ← live!
                                     alloc_iova_fast() → same iova
                                     __domain_mapping()
                                       dma_pte_present() == true ← WARN

Fix: insert iommu_iotlb_sync() immediately before free_iova_fast() on
the lazy path so the IOTLB is fully drained before IOVA reuse.

The strict-mode path already serialises here; this closes the same gap
for lazy/deferred flushing (regression introduced between v6.12.74 and
v6.12.76 — confirmed by reporter).

Reported-by: Giovanni Pancotti <giovanni.pancotti@example.com>
Link: https://bugzilla.kernel.org/show_bug.cgi?id=221389
Fixes: <run: git log v6.12.74..v6.12.76 -- drivers/iommu/dma-iommu.c>
Cc: stable@vger.kernel.org
Signed-off-by: avinash pal <avinashpal441@gmail.com>
---
 drivers/iommu/dma-iommu.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index 0f0caf590..90071cf4a 100644
--- a/drivers/iommu/dma-iommu.c
+++ b/drivers/iommu/dma-iommu.c
@@ -159,6 +159,15 @@ static void fq_ring_free_locked(struct iommu_dma_cookie *cookie, struct iova_fq
 			break;
 
 		iommu_put_pages_list(&fq->entries[idx].freelist);
+/*
+ * Bug fix (Bugzilla #221389, regression v6.12.75/v6.12.76):
+ * Drain the IOTLB before handing the IOVA back to the allocator.
+ * On the lazy-flush path, free_iova_fast() makes the IOVA
+ * immediately reusable.  A concurrent map() call can then receive
+ * the same IOVA while the old PTE is still live in hardware,
+ * triggering a stale-PTE WARN in __domain_mapping().
+ */
+iommu_iotlb_sync(domain, &iotlb_gather);
 		free_iova_fast(&cookie->iovad,
 			       fq->entries[idx].iova_pfn,
 			       fq->entries[idx].pages);
-- 
2.53.0

Re: [PATCH stable 6.12 0/2] iommu/vt-d+dma: fix stale DMA PTE WARN on IOVA reuse (regression v6.12.75)

[Greg KH]

On Thu, Apr 23, 2026 at 03:39:02PM +0530, avinash pal wrote:
> Two-patch series addressing the stale-DMA-PTE WARN_ON regression that
> hits kernels 6.12.75 and 6.12.76 when Intel IOMMU is enabled.
> 
>   Bugzilla : https://bugzilla.kernel.org/show_bug.cgi?id=221389
>   Unaffected: v6.12.74   (confirmed: Giovanni Pancotti, 2026-04-22)
>   Affected  : v6.12.76   (WARN on ATA/SCSI DMA workloads)
>   Workaround: intel_iommu=off
> 
> Root cause
> ==========
> The lazy-flush path in __iommu_dma_unmap_sg() releases an IOVA back to
> the allocator via free_iova_fast() before iommu_iotlb_sync() drains the
> hardware TLB.  A concurrent map() on the same domain receives the same
> IOVA and hits a live PTE in __domain_mapping():
> 
>   CPU 0 (unmap, lazy path)        CPU 1 (concurrent map)
>   ──────────────────────────      ───────────────────────────────
>   iommu_unmap(iova)
>   free_iova_fast(iova)  ← live
>                                   alloc_iova_fast() → same iova
>                                   __domain_mapping()
>                                     dma_pte_present() == true
>                                     WARN_ON_ONCE()          ← hit
> 
> Patches
> =======
> 1/2  iommu/vt-d: fail map loudly on stale DMA PTE
>      - Replaces bare WARN(1,...) with pr_err_ratelimited + WARN_ON_ONCE
>      - Prints vPFN + old PTE value for debugging
>      - Returns -EEXIST; no silent double-map
> 
> 2/2  iommu/dma: sync IOTLB before releasing IOVA on sg unmap
>      - Adds iommu_iotlb_sync() before free_iova_fast() on lazy path
>      - Closes the race window; strict-mode path already does this
> 
> ACTION NEEDED by reviewer: run
>   git log v6.12.74..v6.12.76 -- drivers/iommu/dma-iommu.c
> to identify the offending commit for the Fixes: tag in patch 2/2.
> 
> avinash pal (2):
>   iommu/vt-d: fail map loudly on stale DMA PTE
>   iommu/dma: sync IOTLB before releasing IOVA on sg unmap
> 
>  drivers/iommu/dma-iommu.c   |  9 +++++++
>  drivers/iommu/intel/iommu.c | 50 ++++++++++++++++++++++++++++---------
>  2 files changed, 47 insertions(+), 12 deletions(-)
> 
> 
> base-commit: 444b39ef6108313e8452010b22aaba588e8fb92b
> -- 
> 2.53.0
> 
> 

<formletter>

This is not the correct way to submit patches for inclusion in the
stable kernel tree.  Please read:
    https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
for how to do this properly.

</formletter>

Re: [PATCH stable 6.12 0/2] iommu/vt-d+dma: fix stale DMA PTE WARN on IOVA reuse (regression v6.12.75)

[Robin Murphy]

On 2026-04-23 11:09 am, avinash pal wrote:
> Two-patch series addressing the stale-DMA-PTE WARN_ON regression that
> hits kernels 6.12.75 and 6.12.76 when Intel IOMMU is enabled.
> 
>    Bugzilla : https://bugzilla.kernel.org/show_bug.cgi?id=221389

That appears to be some tracing tool bug?

>    Unaffected: v6.12.74   (confirmed: Giovanni Pancotti, 2026-04-22)
>    Affected  : v6.12.76   (WARN on ATA/SCSI DMA workloads)
>    Workaround: intel_iommu=off
> 
> Root cause
> ==========
> The lazy-flush path in __iommu_dma_unmap_sg() releases an IOVA back to
> the allocator via free_iova_fast() before iommu_iotlb_sync() drains the
> hardware TLB.  A concurrent map() on the same domain receives the same
> IOVA and hits a live PTE in __domain_mapping():

And sorry, but all of this is such complete and utter nonsense that I 
can only assume it's AI slop, as I can't imagine any motivated human 
developer investing the effort to be so wrong in such an intricate level 
of detail.

If the pagetables have got out of sync with the IOVA state because some 
DMA API caller passed the wrong address/size to dma_unmap_*, that's a 
bug in whatever drivers/subsystem is making the DMA API calls - try 
throwing CONFIG_DMA_API_DEBUG at it.

>    CPU 0 (unmap, lazy path)        CPU 1 (concurrent map)
>    ──────────────────────────      ───────────────────────────────
>    iommu_unmap(iova)
>    free_iova_fast(iova)  ← live
>                                    alloc_iova_fast() → same iova
>                                    __domain_mapping()
>                                      dma_pte_present() == true
>                                      WARN_ON_ONCE()          ← hit
> 
> Patches
> =======
> 1/2  iommu/vt-d: fail map loudly on stale DMA PTE
>       - Replaces bare WARN(1,...) with pr_err_ratelimited + WARN_ON_ONCE
>       - Prints vPFN + old PTE value for debugging
>       - Returns -EEXIST; no silent double-map
> 
> 2/2  iommu/dma: sync IOTLB before releasing IOVA on sg unmap
>       - Adds iommu_iotlb_sync() before free_iova_fast() on lazy path
>       - Closes the race window; strict-mode path already does this
> 
> ACTION NEEDED by reviewer: run
>    git log v6.12.74..v6.12.76 -- drivers/iommu/dma-iommu.c
> to identify the offending commit for the Fixes: tag in patch 2/2.

No, that's not how upstream review works. However, since I can guess the 
outcome already:

~/src/linux$ git log v6.12.74..v6.12.76 -- drivers/iommu/dma-iommu.c
~/src/linux$

Oh dear, there were no changes at all!? But... that could only mean that 
the nonsensical hypothesis dreamed up by overpowered autocomplete was in 
fact not true. How could this be!?

Thanks,
Robin.

> 
> avinash pal (2):
>    iommu/vt-d: fail map loudly on stale DMA PTE
>    iommu/dma: sync IOTLB before releasing IOVA on sg unmap
> 
>   drivers/iommu/dma-iommu.c   |  9 +++++++
>   drivers/iommu/intel/iommu.c | 50 ++++++++++++++++++++++++++++---------
>   2 files changed, 47 insertions(+), 12 deletions(-)
> 
> 
> base-commit: 444b39ef6108313e8452010b22aaba588e8fb92b