[PATCH] mm/page_vma_mapped: continue past nonmatching huge PMDs

[PATCH] mm/page_vma_mapped: continue past nonmatching huge PMDs

[Kyle Zeng]

A PTE-mapped large folio can straddle PMD boundaries after an unaligned
mremap().  If the first part is discarded and replaced with an unrelated
huge PMD, page_vma_mapped_walk() stops instead of looking for the rest
of the folio in subsequent PMDs.

This also affects migration entries.  A walk that stops at an unrelated
huge PMD can leave migration PTEs behind when migration or an anonymous
folio split restores the mappings.  Those entries do not hold mapping
references and can outlive the source folio.

Skip the current PMD rather than ending the walk on a flag or PFN
mismatch.  Do the same if the PMD became nonpresent before the locked
recheck.  Release the PMD lock, clear the per-PMD state and advance with
step_forward(), so the existing range limit controls termination.
This covers present, migration and device-private huge PMDs while
preserving the matching-PMD and split-to-PTE paths.

Fixes: ace71a19cec5 ("mm: introduce page_vma_mapped_walk()")
Cc: <stable@vger.kernel.org>
Assisted-by: LLM
Signed-off-by: Kyle Zeng <kylebot@openai.com>
---
 mm/page_vma_mapped.c | 28 +++++++++++++++++++---------
 1 file changed, 19 insertions(+), 9 deletions(-)

diff --git a/mm/page_vma_mapped.c b/mm/page_vma_mapped.c
index 4e964545e5e8..67c8039e9d28 100644
--- a/mm/page_vma_mapped.c
+++ b/mm/page_vma_mapped.c
@@ -258,28 +258,28 @@ bool page_vma_mapped_walk(struct page_vma_mapped_walk *pvmw)
 				softleaf_t entry;
 
 				if (!(pvmw->flags & PVMW_MIGRATION))
-					return not_found(pvmw);
+					goto next_pmd;
 				entry = softleaf_from_pmd(pmde);
 				if (!check_pmd(softleaf_to_pfn(entry), pvmw))
-					return not_found(pvmw);
+					goto next_pmd;
 				return true;
 			} else if (pmd_is_device_private_entry(pmde)) {
 				softleaf_t entry;
 
 				if (pvmw->flags & PVMW_MIGRATION)
-					return not_found(pvmw);
+					goto next_pmd;
 				entry = softleaf_from_pmd(pmde);
 				if (!check_pmd(softleaf_to_pfn(entry), pvmw))
-					return not_found(pvmw);
+					goto next_pmd;
 				return true;
 			} else if (!pmd_present(pmde)) {
-				return not_found(pvmw);
+				goto next_pmd;
 			}
 			if (likely(pmd_trans_huge(pmde))) {
 				if (pvmw->flags & PVMW_MIGRATION)
-					return not_found(pvmw);
+					goto next_pmd;
 				if (!check_pmd(pmd_pfn(pmde), pvmw))
-					return not_found(pvmw);
+					goto next_pmd;
 				return true;
 			}
 			/* THP/device-private pmd was split under us: handle on pte level */
@@ -292,8 +292,7 @@ bool page_vma_mapped_walk(struct page_vma_mapped_walk *pvmw)
 			    (pvmw->nr_pages >= HPAGE_PMD_NR))
 				sync_with_folio_pmd_zap(mm, pvmw->pmd);
 
-			step_forward(pvmw, PMD_SIZE);
-			continue;
+			goto next_pmd;
 		}
 		if (!map_pte(pvmw, &pmde, &ptl)) {
 			if (!pvmw->pte)
@@ -336,6 +335,17 @@ bool page_vma_mapped_walk(struct page_vma_mapped_walk *pvmw)
 			pvmw->ptl = ptl;
 		}
 		goto this_pte;
+next_pmd:
+		/*
+		 * A large folio can be PTE-mapped across PMDs, so a
+		 * nonmatching PMD does not end the walk.
+		 */
+		if (pvmw->ptl) {
+			spin_unlock(pvmw->ptl);
+			pvmw->ptl = NULL;
+		}
+		pvmw->pmd = NULL;
+		step_forward(pvmw, PMD_SIZE);
 	} while (pvmw->address < end);
 
 	return false;
-- 
2.55.0.openai.911.g06873a30d2f3

Re: [PATCH] mm/page_vma_mapped: continue past nonmatching huge PMDs

[Andrew Morton]

On Thu, 15 Oct 2026 18:15:49 -0700 Kyle Zeng <kylebot@openai.com> wrote:

> A PTE-mapped large folio can straddle PMD boundaries after an unaligned
> mremap().  If the first part is discarded and replaced with an unrelated
> huge PMD, page_vma_mapped_walk() stops instead of looking for the rest
> of the folio in subsequent PMDs.
> 
> This also affects migration entries.  A walk that stops at an unrelated
> huge PMD can leave migration PTEs behind when migration or an anonymous
> folio split restores the mappings.  Those entries do not hold mapping
> references and can outlive the source folio.
> 
> Skip the current PMD rather than ending the walk on a flag or PFN
> mismatch.  Do the same if the PMD became nonpresent before the locked
> recheck.  Release the PMD lock, clear the per-PMD state and advance with
> step_forward(), so the existing range limit controls termination.
> This covers present, migration and device-private huge PMDs while
> preserving the matching-PMD and split-to-PTE paths.

As always, when fixing a bug please describe the worst-case
userspace-visible effects of the bug.

I asked $LLM and was told

: The worst credible effects are permanent application hangs, kernel
: crashes, and potentially system-wide denial of service.  Stale
: migration entries can refer to freed and reused physical pages, causing
: page faults to access unrelated folio metadata.  Memory corruption is
: possible but unproven; cross-process information disclosure has not
: been established.

But you have an LLM too!  So please never again send a bugfix without
this info.

Also please explain whether there's a reproducer and if so, at least
describe it and confirm the before-and-after results.

Thanks.

Re: [PATCH] mm/page_vma_mapped: continue past nonmatching huge PMDs

[Kyle Zeng]

On Thu, Oct 15, 2026 at 07:20:20PM -0700, Andrew Morton wrote:
> On Thu, 15 Oct 2026 18:15:49 -0700 Kyle Zeng <kylebot@openai.com> wrote:
> 
> > A PTE-mapped large folio can straddle PMD boundaries after an unaligned
> > mremap().  If the first part is discarded and replaced with an unrelated
> > huge PMD, page_vma_mapped_walk() stops instead of looking for the rest
> > of the folio in subsequent PMDs.
> > 
> > This also affects migration entries.  A walk that stops at an unrelated
> > huge PMD can leave migration PTEs behind when migration or an anonymous
> > folio split restores the mappings.  Those entries do not hold mapping
> > references and can outlive the source folio.
> > 
> > Skip the current PMD rather than ending the walk on a flag or PFN
> > mismatch.  Do the same if the PMD became nonpresent before the locked
> > recheck.  Release the PMD lock, clear the per-PMD state and advance with
> > step_forward(), so the existing range limit controls termination.
> > This covers present, migration and device-private huge PMDs while
> > preserving the matching-PMD and split-to-PTE paths.
> 
> As always, when fixing a bug please describe the worst-case
> userspace-visible effects of the bug.
> 
> I asked $LLM and was told
> 
> : The worst credible effects are permanent application hangs, kernel
> : crashes, and potentially system-wide denial of service.  Stale
> : migration entries can refer to freed and reused physical pages, causing
> : page faults to access unrelated folio metadata.  Memory corruption is
> : possible but unproven; cross-process information disclosure has not
> : been established.
> 
> But you have an LLM too!  So please never again send a bugfix without
> this info.
> 
> Also please explain whether there's a reproducer and if so, at least
> describe it and confirm the before-and-after results.
> 
> Thanks.
> 

Hi Andrew,

This issue can lead to memory corruption and I have a reproducer for it.
I can update the description and send in a v2 if you think it is proper.

Best,
Kyle