From: avinash pal <avinashpal441@gmail.com>
To: David Woodhouse <dwmw2@infradead.org>
Cc: Lu Baolu <baolu.lu@linux.intel.com>,
Joerg Roedel <joro@8bytes.org>, Will Deacon <will@kernel.org>,
Robin Murphy <robin.murphy@arm.com>,
avinash pal <avinashpal441@gmail.com>,
iommu@lists.linux.dev, linux-kernel@vger.kernel.org,
stable@vger.kernel.org,
Giovanni Pancotti <giovanni.pancotti@example.com>
Subject: [PATCH stable 6.12 1/2] iommu/vt-d: fail map loudly on stale DMA PTE
Date: Thu, 23 Apr 2026 15:39:03 +0530 [thread overview]
Message-ID: <20260423100904.5966-2-avinashpal441@gmail.com> (raw)
In-Reply-To: <20260423100904.5966-1-avinashpal441@gmail.com>
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
next prev parent reply other threads:[~2026-04-23 10:09 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-23 10:09 [PATCH stable 6.12 0/2] iommu/vt-d+dma: fix stale DMA PTE WARN on IOVA reuse (regression v6.12.75) avinash pal
2026-04-23 10:09 ` avinash pal [this message]
2026-04-23 10:09 ` [PATCH stable 6.12 2/2] iommu/dma: sync IOTLB before releasing IOVA on sg unmap avinash pal
2026-04-23 11:10 ` [PATCH stable 6.12 0/2] iommu/vt-d+dma: fix stale DMA PTE WARN on IOVA reuse (regression v6.12.75) Greg KH
2026-04-23 11:34 ` Robin Murphy
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=20260423100904.5966-2-avinashpal441@gmail.com \
--to=avinashpal441@gmail.com \
--cc=baolu.lu@linux.intel.com \
--cc=dwmw2@infradead.org \
--cc=giovanni.pancotti@example.com \
--cc=iommu@lists.linux.dev \
--cc=joro@8bytes.org \
--cc=linux-kernel@vger.kernel.org \
--cc=robin.murphy@arm.com \
--cc=stable@vger.kernel.org \
--cc=will@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