Fix incorrect access of hugetlb pte entries

PATCH Applied Dev Jain 5 participants 27 messages Jul 3 – Jul 22

Subsystems (7)

Stable branch Memory management arm64 Memory mapping +3 more subsystems

lore

Share & tools

lore

Dev Jain

author

2026-07-03 11:42 UTC #0 lore raw

v3 cover Fix incorrect access of hugetlb pte entries

There are various places which use ptep_get() to get the pte entry corresponding to a hugetlb folio. Some arches (like s390) have special handling to compute the pteval, so they provide huge_ptep_get(). Use this helper consistently.

Additionally, some code paths may provide huge_ptep_get with an unaligned address. This is a problem on arm64 (I checked other arches and it looks fine for them), which is fixed in patch 1. The fix is made to be
backport-friendly: the cleaner fix would be to perhaps pass the hstate to huge_ptep_get() - that is wider churn and we can do that later.

---
v2->v3:
- Place comment at appropriate place in patches 2 and 3
- Modify indentation in patch 2, patch 6

v1->v2:
- Add patch 1
- Mention s390 in cover letter

Dev Jain (6):
arm64: make huge_ptep_get handled unaligned addresses mm/rmap: use huge_ptep_get() in try_to_unmap_one() mm/rmap: use huge_ptep_get() in try_to_migrate_one() mm/migrate: use huge_ptep_get() in remove_migration_pte() mm/page_vma_mapped: use huge_ptep_get() for hugetlb mm/mprotect: use huge_ptep_get() for hugetlb

 arch/arm64/mm/hugetlbpage.c |  2 +-
 include/linux/hugetlb.h     |  2 ++
 mm/migrate.c                |  6 +++++-
 mm/mprotect.c               | 12 +++++++++---
 mm/page_vma_mapped.c        |  8 +++++++-
 mm/rmap.c                   | 32 ++++++++++++++++++++------------
 6 files changed, 44 insertions(+), 18 deletions(-)

Signature · 1 line

2.43.0

Dev Jain

author

2026-07-03 11:42 UTC #1 lore raw

PATCH v3 1/6 arm64: make huge_ptep_get handled unaligned addresses

huge_ptep_get() can be handed a virtual address pointing to the middle of a contpmd/contpte mapped hugetlb folio (examples of callers are pagemap_hugetlb_range, page_mapped_in_vma).

The arm64 helper rewalks the pgtables in find_num_contig to answer whether the huge pte we have maps a contpmd or a contpte hugetlb folio, and returns CONT_PMDS or CONT_PTES, so that it can collect a/d bits over the contiguous ptes. We can falsely return CONT_PTES instead of CONT_PMDS if the addr is not aligned.

Fix this by aligning the pmdp pointer down to a contpmd base before checking equality with the passed huge pte pointer, to correctly answer whether the huge pte is the base of a contpmd block.

Fixes 29cb80519689 ("arm64: hugetlb: Cleanup huge_pte size discovery mechanisms")

Cc [email protected]

Acked-by David Hildenbrand (Arm) <[email protected]>

Signed-off-by Dev Jain <[email protected]>

---
 arch/arm64/mm/hugetlbpage.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

arch/arm64/mm/hugetlbpage.c +1 -1

index 30772a909aea3..8e799c1fe0aa6 100644
@@ -87,7 +87,7 @@ static int find_num_contig(struct mm_struct *mm, unsigned long addr,
 	p4dp = p4d_offset(pgdp, addr);
 	pudp = pud_offset(p4dp, addr);
 	pmdp = pmd_offset(pudp, addr);
-	if ((pte_t *)pmdp == ptep) {
+	if ((pte_t *)PTR_ALIGN_DOWN(pmdp, sizeof(*pmdp) * CONT_PMDS) == ptep) {
 		*pgsize = PMD_SIZE;
 		return CONT_PMDS;
 	}

Signature · 1 line

2.43.0

Muchun Song

maintainer Acked-by on v3 1/6

2026-07-04 02:43 UTC #2 lore raw

Re: [PATCH v3 1/6] arm64: make huge_ptep_get handled unaligned addresses

Quoted 14 lines · Dev Jain

huge_ptep_get() can be handed a virtual address pointing to the middle of a contpmd/contpte mapped hugetlb folio (examples of callers are pagemap_hugetlb_range, page_mapped_in_vma).
The arm64 helper rewalks the pgtables in find_num_contig to answer whether the huge pte we have maps a contpmd or a contpte hugetlb folio, and returns CONT_PMDS or CONT_PTES, so that it can collect a/d bits over the contiguous ptes. We can falsely return CONT_PTES instead of CONT_PMDS if the addr is not aligned.

Quoted 8 lines

Fix this by aligning the pmdp pointer down to a contpmd base before checking equality with the passed huge pte pointer, to correctly answer whether the huge pte is the base of a contpmd block.
Fixes 29cb80519689 ("arm64: hugetlb: Cleanup huge_pte size discovery mechanisms")
Cc [email protected]
Acked-by David Hildenbrand (Arm) <[email protected]>
Signed-off-by Dev Jain <[email protected]>

Acked-by Muchun Song <[email protected]>

Thanks.

Andrew Morton

maintainer

2026-07-05 07:36 UTC #3 lore raw

Re: [PATCH v3 1/6] arm64: make huge_ptep_get handled unaligned addresses

In reply to Dev Jain

Quoted 10 lines · On Fri, 3 Jul 2026 11:41:54 +0000 Dev Jain <[email protected]> wrote:

huge_ptep_get() can be handed a virtual address pointing to the middle of a contpmd/contpte mapped hugetlb folio (examples of callers are pagemap_hugetlb_range, page_mapped_in_vma).
The arm64 helper rewalks the pgtables in find_num_contig to answer whether the huge pte we have maps a contpmd or a contpte hugetlb folio, and returns CONT_PMDS or CONT_PTES, so that it can collect a/d bits over the contiguous ptes. We can falsely return CONT_PTES instead of CONT_PMDS if the addr is not aligned.

Quoted 6 lines

Fix this by aligning the pmdp pointer down to a contpmd base before checking equality with the passed huge pte pointer, to correctly answer whether the huge pte is the base of a contpmd block.
Fixes 29cb80519689 ("arm64: hugetlb: Cleanup huge_pte size discovery mechanisms")
Cc [email protected]

Please describe the userspace-visible effects of bugs when fixing them. Particularly when cc:stable is proposed. Thanks.

Dev Jain

author

2026-07-05 08:08 UTC #4 lore raw

Re: [PATCH v3 1/6] arm64: make huge_ptep_get handled unaligned addresses

Quoted 16 lines · Andrew Morton

Quoted 14 lines · On Fri, 3 Jul 2026 11:41:54 +0000 Dev Jain <[email protected]> wrote:
huge_ptep_get() can be handed a virtual address pointing to the middle of a contpmd/contpte mapped hugetlb folio (examples of callers are pagemap_hugetlb_range, page_mapped_in_vma).
The arm64 helper rewalks the pgtables in find_num_contig to answer whether the huge pte we have maps a contpmd or a contpte hugetlb folio, and returns CONT_PMDS or CONT_PTES, so that it can collect a/d bits over the contiguous ptes. We can falsely return CONT_PTES instead of CONT_PMDS if the addr is not aligned.
Fix this by aligning the pmdp pointer down to a contpmd base before checking equality with the passed huge pte pointer, to correctly answer whether the huge pte is the base of a contpmd block.

Quoted 5 lines

Quoted 2 lines
Fixes 29cb80519689 ("arm64: hugetlb: Cleanup huge_pte size discovery mechanisms")
Cc [email protected]
Please describe the userspace-visible effects of bugs when fixing them. Particularly when cc:stable is proposed. Thanks.

Forgot for this one. It should be, on systems where CONT_PTES != CONT_PMDS (meaning page size is 16K) we could collect excess a/d bit state, meaning extra work for the kernel.

Quoted 1 line

David Hildenbrand (Arm)

maintainer

2026-07-06 08:46 UTC #5 lore raw

Re: [PATCH v3 1/6] arm64: make huge_ptep_get handled unaligned addresses

Quoted 22 lines · Dev Jain

Quoted 19 lines · Andrew Morton
Quoted 16 lines · On Fri, 3 Jul 2026 11:41:54 +0000 Dev Jain <[email protected]> wrote:
huge_ptep_get() can be handed a virtual address pointing to the middle of a contpmd/contpte mapped hugetlb folio (examples of callers are pagemap_hugetlb_range, page_mapped_in_vma).
The arm64 helper rewalks the pgtables in find_num_contig to answer whether the huge pte we have maps a contpmd or a contpte hugetlb folio, and returns CONT_PMDS or CONT_PTES, so that it can collect a/d bits over the contiguous ptes. We can falsely return CONT_PTES instead of CONT_PMDS if the addr is not aligned.
Fix this by aligning the pmdp pointer down to a contpmd base before checking equality with the passed huge pte pointer, to correctly answer whether the huge pte is the base of a contpmd block.
Fixes 29cb80519689 ("arm64: hugetlb: Cleanup huge_pte size discovery mechanisms")
Cc [email protected]

Quoted 6 lines

Quoted 2 lines
Please describe the userspace-visible effects of bugs when fixing them. Particularly when cc:stable is proposed. Thanks.
Forgot for this one. It should be, on systems where CONT_PTES != CONT_PMDS (meaning page size is 16K) we could collect excess a/d bit state, meaning extra work for the kernel.

Even worse, right? We could walk 128 entries, when we really should just walk 16 (IIRC) entries, possibly reading garbage or even worse, into a memory hole at the end of memory?

Signature · 3 lines

Cheers,

David

Dev Jain

author

2026-07-06 10:52 UTC #6 lore raw

Re: [PATCH v3 1/6] arm64: make huge_ptep_get handled unaligned addresses

Quoted 26 lines · David Hildenbrand (Arm)

Quoted 25 lines · Dev Jain
Quoted 21 lines · Andrew Morton
Quoted 10 lines · On Fri, 3 Jul 2026 11:41:54 +0000 Dev Jain <[email protected]> wrote:
huge_ptep_get() can be handed a virtual address pointing to the middle of a contpmd/contpte mapped hugetlb folio (examples of callers are pagemap_hugetlb_range, page_mapped_in_vma).
The arm64 helper rewalks the pgtables in find_num_contig to answer whether the huge pte we have maps a contpmd or a contpte hugetlb folio, and returns CONT_PMDS or CONT_PTES, so that it can collect a/d bits over the contiguous ptes. We can falsely return CONT_PTES instead of CONT_PMDS if the addr is not aligned.
Quoted 6 lines
Fix this by aligning the pmdp pointer down to a contpmd base before checking equality with the passed huge pte pointer, to correctly answer whether the huge pte is the base of a contpmd block.
Fixes 29cb80519689 ("arm64: hugetlb: Cleanup huge_pte size discovery mechanisms")
Cc [email protected]
Please describe the userspace-visible effects of bugs when fixing them. Particularly when cc:stable is proposed. Thanks.

Quoted 7 lines

Quoted 3 lines
Forgot for this one. It should be, on systems where CONT_PTES != CONT_PMDS (meaning page size is 16K) we could collect excess a/d bit state, meaning extra work for the kernel.
Even worse, right? We could walk 128 entries, when we really should just walk 16 (IIRC) entries, possibly reading garbage or even worse, into a memory hole at the end of memory?

Hmm I was thinking that the checks pte_dirty() and pte_young() wouldn't care whether the pte is garbage. But, we could actually dereference a ptep pointer not having backing memory at all.

Does the following sound good?

"On systems where CONT_PTES != CONT_PMDS (meaning page size is 16K), we could collect excess a/d bit state, meaning extra work for the kernel. Even worse, we may iterate beyond the PTE table and dereference a garbage ptep pointer to access physical memory we don't own. Since the ptep pointer is a linear map address, we may run off the end of the linear map, dereference a VA not mapped into the kernel pgtables and cause kernel panic."

Although I checked on arm64, there is no case in which there is a hole after the linear map, but still that assumption shouldn't be made.

Quoted 1 line

Dev Jain

author

2026-07-06 10:55 UTC #7 lore raw

Re: [PATCH v3 1/6] arm64: make huge_ptep_get handled unaligned addresses

Quoted 50 lines · Dev Jain

Quoted 26 lines · David Hildenbrand (Arm)
Quoted 25 lines · Dev Jain
Quoted 21 lines · Andrew Morton
Quoted 10 lines · On Fri, 3 Jul 2026 11:41:54 +0000 Dev Jain <[email protected]> wrote:
huge_ptep_get() can be handed a virtual address pointing to the middle of a contpmd/contpte mapped hugetlb folio (examples of callers are pagemap_hugetlb_range, page_mapped_in_vma).
The arm64 helper rewalks the pgtables in find_num_contig to answer whether the huge pte we have maps a contpmd or a contpte hugetlb folio, and returns CONT_PMDS or CONT_PTES, so that it can collect a/d bits over the contiguous ptes. We can falsely return CONT_PTES instead of CONT_PMDS if the addr is not aligned.
Quoted 6 lines
Fix this by aligning the pmdp pointer down to a contpmd base before checking equality with the passed huge pte pointer, to correctly answer whether the huge pte is the base of a contpmd block.
Fixes 29cb80519689 ("arm64: hugetlb: Cleanup huge_pte size discovery mechanisms")
Cc [email protected]
Please describe the userspace-visible effects of bugs when fixing them. Particularly when cc:stable is proposed. Thanks.
Quoted 7 lines
Quoted 3 lines
Forgot for this one. It should be, on systems where CONT_PTES != CONT_PMDS (meaning page size is 16K) we could collect excess a/d bit state, meaning extra work for the kernel.
Even worse, right? We could walk 128 entries, when we really should just walk 16 (IIRC) entries, possibly reading garbage or even worse, into a memory hole at the end of memory?
Hmm I was thinking that the checks pte_dirty() and pte_young() wouldn't care whether the pte is garbage. But, we could actually dereference a ptep pointer not having backing memory at all.
Does the following sound good?
"On systems where CONT_PTES != CONT_PMDS (meaning page size is 16K), we could collect excess a/d bit state, meaning extra work for the kernel. Even worse, we may iterate beyond the PTE table and dereference a garbage ptep pointer to access physical memory we don't own. Since the ptep pointer is a linear map address, we may run off the end of the linear map, dereference a VA not mapped into the kernel pgtables and cause kernel panic."

Quoted 2 lines

Although I checked on arm64, there is no case in which there is a hole after the linear map, but still that assumption shouldn't be made.

Oh but we could access a linear map address which corresponds to a DRAM hole, meaning there is no entry in the kernel pgtable.

Quoted 5 lines

Quoted 3 lines

David Hildenbrand (Arm)

maintainer

2026-07-06 14:04 UTC #8 lore raw

Re: [PATCH v3 1/6] arm64: make huge_ptep_get handled unaligned addresses

Quoted 24 lines · Dev Jain

Quoted 21 lines · Dev Jain
Quoted 4 lines · David Hildenbrand (Arm)
Even worse, right? We could walk 128 entries, when we really should just walk 16 (IIRC) entries, possibly reading garbage or even worse, into a memory hole at the end of memory?
Hmm I was thinking that the checks pte_dirty() and pte_young() wouldn't care whether the pte is garbage. But, we could actually dereference a ptep pointer not having backing memory at all.
Does the following sound good?
"On systems where CONT_PTES != CONT_PMDS (meaning page size is 16K), we could collect excess a/d bit state, meaning extra work for the kernel. Even worse, we may iterate beyond the PTE table and dereference a garbage ptep pointer to access physical memory we don't own. Since the ptep pointer is a linear map address, we may run off the end of the linear map, dereference a VA not mapped into the kernel pgtables and cause kernel panic."

Quoted 5 lines

Quoted 2 lines
Although I checked on arm64, there is no case in which there is a hole after the linear map, but still that assumption shouldn't be made.
Oh but we could access a linear map address which corresponds to a DRAM hole, meaning there is no entry in the kernel pgtable.

Yes, exactly. With debug-pagealloc and things like that we might have many holes in the direct map.

Signature · 3 lines

Cheers,

David

Will Deacon

maintainer

2026-07-16 12:49 UTC #9 lore raw

Re: [PATCH v3 1/6] arm64: make huge_ptep_get handled unaligned addresses

Quoted 25 lines · David Hildenbrand (Arm)

Quoted 24 lines · Dev Jain
Quoted 21 lines · Dev Jain
Quoted 4 lines · David Hildenbrand (Arm)
Even worse, right? We could walk 128 entries, when we really should just walk 16 (IIRC) entries, possibly reading garbage or even worse, into a memory hole at the end of memory?
Hmm I was thinking that the checks pte_dirty() and pte_young() wouldn't care whether the pte is garbage. But, we could actually dereference a ptep pointer not having backing memory at all.
Does the following sound good?
"On systems where CONT_PTES != CONT_PMDS (meaning page size is 16K), we could collect excess a/d bit state, meaning extra work for the kernel. Even worse, we may iterate beyond the PTE table and dereference a garbage ptep pointer to access physical memory we don't own. Since the ptep pointer is a linear map address, we may run off the end of the linear map, dereference a VA not mapped into the kernel pgtables and cause kernel panic."

Quoted 8 lines

Quoted 5 lines
Quoted 2 lines
Although I checked on arm64, there is no case in which there is a hole after the linear map, but still that assumption shouldn't be made.
Oh but we could access a linear map address which corresponds to a DRAM hole, meaning there is no entry in the kernel pgtable.
Yes, exactly. With debug-pagealloc and things like that we might have many holes in the direct map.

I think this one patch should go in as a fix.

Andrew, do you mind if I pick it via arm64? If you'd rather manage the whole lot, please can you send just this one as a fix for this cycle?

Thanks,

Will

Dev Jain

author

2026-07-03 11:42 UTC #10 lore raw

PATCH v3 2/6 mm/rmap: use huge_ptep_get() in try_to_unmap_one()

In reply to Dev Jain

try_to_unmap_one() handles hugetlb folios when memory failure needs to replace a poisoned hugetlb mapping with a hwpoison entry. In that case page_vma_mapped_walk() returns the pte pointer to the hugetlb folio in pvmw.pte, but the code reads it with ptep_get().

On arches which provide their own huge_ptep_get() to dereference a huge pte pointer, accessing via ptep_get() would cause pte_pfn(), pte_present() etc to misbehave.

It is not clear whether this has a trivially visible effect to userspace.

Just use huge_ptep_get() for dereferencing a huge pte pointer.

Fixes c7ab0d2fdc84 ("mm: convert try_to_unmap_one() to use page_vma_mapped_walk()")

Cc [email protected]

Reported-by David Hildenbrand <[email protected]>

Signed-off-by Dev Jain <[email protected]>

---
 include/linux/hugetlb.h |  2 ++
 mm/rmap.c               | 16 ++++++++++------
 2 files changed, 12 insertions(+), 6 deletions(-)

include/linux/hugetlb.h +2 -0

index 2abaf99321e90..6996d02acf171 100644
@@ -1261,6 +1261,8 @@ static inline void hugetlb_count_sub(long l, struct mm_struct *mm)
 {
 }
 
+pte_t huge_ptep_get(struct mm_struct *mm, unsigned long addr, pte_t *ptep);
+
 static inline pte_t huge_ptep_clear_flush(struct vm_area_struct *vma,
 					  unsigned long addr, pte_t *ptep)
 {

mm/rmap.c +10 -6

index 1c77d5dc06e9f..03737daa348c0 100644
@@ -2095,14 +2095,19 @@ static bool try_to_unmap_one(struct folio *folio, struct vm_area_struct *vma,
 		/* Unexpected PMD-mapped THP? */
 		VM_BUG_ON_FOLIO(!pvmw.pte, folio);
 
-		/*
-		 * Handle PFN swap PTEs, such as device-exclusive ones, that
-		 * actually map pages.
-		 */
-		pteval = ptep_get(pvmw.pte);
+		address = pvmw.address;
+		if (folio_test_hugetlb(folio)) {
+			pteval = huge_ptep_get(mm, address, pvmw.pte);
+		} else {
+			pteval = ptep_get(pvmw.pte);
+		}
 		if (likely(pte_present(pteval))) {
 			pfn = pte_pfn(pteval);
 		} else {
+			/*
+			 * Handle PFN swap PTEs, such as device-exclusive ones,
+			 * that actually map pages.
+			 */
 			const softleaf_t entry = softleaf_from_pte(pteval);
 
 			pfn = softleaf_to_pfn(entry);

@@ -2110,7 +2115,6 @@ static bool try_to_unmap_one(struct folio *folio, struct vm_area_struct *vma,
 		}
 
 		subpage = folio_page(folio, pfn - folio_pfn(folio));
-		address = pvmw.address;
 		anon_exclusive = folio_test_anon(folio) &&
 				 PageAnonExclusive(subpage);

Signature · 1 line

2.43.0

Muchun Song

maintainer Reviewed-by on v3 2/6

2026-07-04 02:45 UTC #11 lore raw

Re: [PATCH v3 2/6] mm/rmap: use huge_ptep_get() in try_to_unmap_one()

Quoted 13 lines · Dev Jain

try_to_unmap_one() handles hugetlb folios when memory failure needs to replace a poisoned hugetlb mapping with a hwpoison entry. In that case page_vma_mapped_walk() returns the pte pointer to the hugetlb folio in pvmw.pte, but the code reads it with ptep_get().
On arches which provide their own huge_ptep_get() to dereference a huge pte pointer, accessing via ptep_get() would cause pte_pfn(), pte_present() etc to misbehave.

Quoted 8 lines

It is not clear whether this has a trivially visible effect to userspace.
Just use huge_ptep_get() for dereferencing a huge pte pointer.
Fixes c7ab0d2fdc84 ("mm: convert try_to_unmap_one() to use page_vma_mapped_walk()")
Cc [email protected]
Reported-by David Hildenbrand <[email protected]>
Signed-off-by Dev Jain <[email protected]>

Reviewed-by Muchun Song <[email protected]>

Thanks.

David Hildenbrand (Arm)

maintainer Acked-by on v3 2/6

2026-07-06 08:46 UTC #12 lore raw

Re: [PATCH v3 2/6] mm/rmap: use huge_ptep_get() in try_to_unmap_one()

In reply to Dev Jain

Quoted 11 lines · Dev Jain

try_to_unmap_one() handles hugetlb folios when memory failure needs to replace a poisoned hugetlb mapping with a hwpoison entry. In that case page_vma_mapped_walk() returns the pte pointer to the hugetlb folio in pvmw.pte, but the code reads it with ptep_get().
On arches which provide their own huge_ptep_get() to dereference a huge pte pointer, accessing via ptep_get() would cause pte_pfn(), pte_present() etc to misbehave.
It is not clear whether this has a trivially visible effect to userspace.

Quoted 7 lines

Just use huge_ptep_get() for dereferencing a huge pte pointer.
Fixes c7ab0d2fdc84 ("mm: convert try_to_unmap_one() to use page_vma_mapped_walk()")
Cc [email protected]
Reported-by David Hildenbrand <[email protected]>
Signed-off-by Dev Jain <[email protected]>
---

Acked-by David Hildenbrand (Arm) <[email protected]>

Signature · 3 lines

Cheers,

David

Dev Jain

author

2026-07-03 11:42 UTC #13 lore raw

PATCH v3 3/6 mm/rmap: use huge_ptep_get() in try_to_migrate_one()

In reply to Dev Jain

try_to_migrate_one() is used by folio migration to replace a present mapping with a migration entry. For hugetlb folios, page_vma_mapped_walk() returns the pte pointer to the hugetlb folio in pvmw.pte, but the code reads the huge pte entry with ptep_get().

On arches which provide their own huge_ptep_get() to dereference a huge pte pointer, accessing via ptep_get() would cause pte_pfn(), pte_present() etc to misbehave.

It is not clear whether this has a trivially visible effect to userspace.

Use huge_ptep_get() to dereference a huge pte pointer.

Commit a98a2f0c8ce1 copied the bug from try_to_unmap_one into try_to_migrate_one.

Fixes a98a2f0c8ce1 ("mm/rmap: split migration into its own function")

Cc [email protected]

Acked-by Muchun Song <[email protected]>

Signed-off-by Dev Jain <[email protected]>

---
 mm/rmap.c | 16 ++++++++++------
 1 file changed, 10 insertions(+), 6 deletions(-)

mm/rmap.c +10 -6

index 03737daa348c0..ea4ad5e662f7d 100644
@@ -2505,14 +2505,19 @@ static bool try_to_migrate_one(struct folio *folio, struct vm_area_struct *vma,
 		/* Unexpected PMD-mapped THP? */
 		VM_BUG_ON_FOLIO(!pvmw.pte, folio);
 
-		/*
-		 * Handle PFN swap PTEs, such as device-exclusive ones, that
-		 * actually map pages.
-		 */
-		pteval = ptep_get(pvmw.pte);
+		address = pvmw.address;
+		if (folio_test_hugetlb(folio)) {
+			pteval = huge_ptep_get(mm, address, pvmw.pte);
+		} else {
+			pteval = ptep_get(pvmw.pte);
+		}
 		if (likely(pte_present(pteval))) {
 			pfn = pte_pfn(pteval);
 		} else {
+			/*
+			 * Handle PFN swap PTEs, such as device-exclusive ones,
+			 * that actually map pages.
+			 */
 			const softleaf_t entry = softleaf_from_pte(pteval);
 
 			pfn = softleaf_to_pfn(entry);

@@ -2520,7 +2525,6 @@ static bool try_to_migrate_one(struct folio *folio, struct vm_area_struct *vma,
 		}
 
 		subpage = folio_page(folio, pfn - folio_pfn(folio));
-		address = pvmw.address;
 		anon_exclusive = folio_test_anon(folio) &&
 				 PageAnonExclusive(subpage);

Signature · 1 line

2.43.0

David Hildenbrand (Arm)

maintainer Acked-by on v3 3/6

2026-07-06 08:46 UTC #14 lore raw

Re: [PATCH v3 3/6] mm/rmap: use huge_ptep_get() in try_to_migrate_one()

Quoted 13 lines · Dev Jain

try_to_migrate_one() is used by folio migration to replace a present mapping with a migration entry. For hugetlb folios, page_vma_mapped_walk() returns the pte pointer to the hugetlb folio in pvmw.pte, but the code reads the huge pte entry with ptep_get().
On arches which provide their own huge_ptep_get() to dereference a huge pte pointer, accessing via ptep_get() would cause pte_pfn(), pte_present() etc to misbehave.
It is not clear whether this has a trivially visible effect to userspace.
Use huge_ptep_get() to dereference a huge pte pointer.

Quoted 8 lines

Commit a98a2f0c8ce1 copied the bug from try_to_unmap_one into try_to_migrate_one.
Fixes a98a2f0c8ce1 ("mm/rmap: split migration into its own function")
Cc [email protected]
Acked-by Muchun Song <[email protected]>
Signed-off-by Dev Jain <[email protected]>
---

Acked-by David Hildenbrand (Arm) <[email protected]>

Signature · 3 lines

Cheers,

David

Dev Jain

author

2026-07-03 11:43 UTC #15 lore raw

PATCH v3 4/6 mm/migrate: use huge_ptep_get() in remove_migration_pte()

In reply to Dev Jain

remove_migration_pte() converts migration entries back to present PTEs after folio migration completes. For hugetlb folios, page_vma_mapped_walk() returns the pte pointer to the hugetlb folio in pvmw.pte, but the code reads it with ptep_get().

On arches which provide their own huge_ptep_get() to dereference a huge pte pointer, accessing via ptep_get() would cause pte_pfn(), pte_present() etc to misbehave.

It is not clear whether this has a trivially visible effect to userspace.

Use huge_ptep_get() to dereference a huge pte pointer.

Fixes 290408d4a250 ("hugetlb: hugepage migration core")

Cc [email protected]

Acked-by Muchun Song <[email protected]>

Acked-by David Hildenbrand (Arm) <[email protected]>

Signed-off-by Dev Jain <[email protected]>

---
 mm/migrate.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

mm/migrate.c +5 -1

index d9b23909d716c..c65f0f43df7eb 100644
@@ -371,7 +371,11 @@ static bool remove_migration_pte(struct folio *folio,
 			continue;
 		}
 #endif
-		old_pte = ptep_get(pvmw.pte);
+		if (folio_test_hugetlb(folio))
+			old_pte = huge_ptep_get(vma->vm_mm, pvmw.address,
+						pvmw.pte);
+		else
+			old_pte = ptep_get(pvmw.pte);
 		if (rmap_walk_arg->map_unused_to_zeropage &&
 		    try_to_map_unused_to_zeropage(&pvmw, folio, old_pte, idx))
 			continue;

Signature · 1 line

2.43.0

Dev Jain

author

2026-07-03 11:43 UTC #16 lore raw

PATCH v3 5/6 mm/page_vma_mapped: use huge_ptep_get() for hugetlb

In reply to Dev Jain

check_pte() is the final validation step in page_vma_mapped_walk(). It reads pvmw->pte with ptep_get() to decide whether the entry maps the PFN range being walked. For hugetlb VMAs, that pointer refers to a hugetlb entry.

On arches which provide their own huge_ptep_get() to dereference a huge pte pointer, accessing via ptep_get() would cause pte_pfn(), pte_present() etc to misbehave.

It is not clear whether this has a trivially visible effect to userspace.

Use huge_ptep_get() to dereference a huge pte pointer.

Fixes ace71a19cec5 ("mm: introduce page_vma_mapped_walk()")

Cc [email protected]

Acked-by David Hildenbrand (Arm) <[email protected]>

Reviewed-by Muchun Song <[email protected]>

Signed-off-by Dev Jain <[email protected]>

---
 mm/page_vma_mapped.c | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

mm/page_vma_mapped.c +7 -1

index 2ccbabfb2cc17..18e1d341f463c 100644
@@ -107,7 +107,13 @@ static bool map_pte(struct page_vma_mapped_walk *pvmw, pmd_t *pmdvalp,
 static bool check_pte(struct page_vma_mapped_walk *pvmw, unsigned long pte_nr)
 {
 	unsigned long pfn;
-	pte_t ptent = ptep_get(pvmw->pte);
+	pte_t ptent;
+
+	if (is_vm_hugetlb_page(pvmw->vma))
+		ptent = huge_ptep_get(pvmw->vma->vm_mm, pvmw->address,
+				      pvmw->pte);
+	else
+		ptent = ptep_get(pvmw->pte);
 
 	if (pvmw->flags & PVMW_MIGRATION) {
 		const softleaf_t entry = softleaf_from_pte(ptent);

Signature · 1 line

2.43.0

Dev Jain

author

2026-07-03 11:43 UTC #17 lore raw

PATCH v3 6/6 mm/mprotect: use huge_ptep_get() for hugetlb

In reply to Dev Jain

prot_none_hugetlb_entry() is the hugetlb callback for the early mprotect(PROT_NONE) PFN permission walk on x86.

The callback passes the decoded PFN to pfn_modify_allowed(). For a hugetlb callback, the pte pointer refers to a hugetlb entry. On architectures where hugetlb entries need huge_ptep_get(), reading that entry with ptep_get() can make the permission check use the wrong PFN.

Use huge_ptep_get() before decoding the hugetlb PFN.

Currently there is no path which can trigger a bug: huge_ptep_get() is a simple ptep_get() for x86, and the prot_none walk occurs only for x86.

So no need to backport - use the correct helper anyways.

Fixes 42e4089c7890 ("x86/speculation/l1tf: Disallow non privileged high MMIO PROT_NONE mappings")

Reviewed-by Muchun Song <[email protected]>

Signed-off-by Dev Jain <[email protected]>

---
 mm/mprotect.c | 12 +++++++++---
 1 file changed, 9 insertions(+), 3 deletions(-)

mm/mprotect.c +9 -3

index 9cbf932b028cf..6360d8a378023 100644
@@ -699,14 +699,20 @@ static int prot_none_pte_entry(pte_t *pte, unsigned long addr,
 		0 : -EACCES;
 }
 
+#ifdef CONFIG_HUGETLB_PAGE
 static int prot_none_hugetlb_entry(pte_t *pte, unsigned long hmask,
 				   unsigned long addr, unsigned long next,
 				   struct mm_walk *walk)
 {
-	return pfn_modify_allowed(pte_pfn(ptep_get(pte)),
-				  *(pgprot_t *)(walk->private)) ?
-		0 : -EACCES;
+	const pte_t entry = huge_ptep_get(walk->mm, addr, pte);
+
+	if (pfn_modify_allowed(pte_pfn(entry), *(pgprot_t *)(walk->private)))
+		return 0;
+	return -EACCESS;
 }
+#else
+#define prot_none_hugetlb_entry	NULL
+#endif
 
 static int prot_none_test(unsigned long addr, unsigned long next,
 			  struct mm_walk *walk)

Signature · 1 line

2.43.0

Andrew Morton

maintainer

2026-07-05 08:33 UTC #18 lore raw

Re: [PATCH v3 6/6] mm/mprotect: use huge_ptep_get() for hugetlb

Quoted 26 lines · On Fri, 3 Jul 2026 11:41:59 +0000 Dev Jain <[email protected]> wrote:

prot_none_hugetlb_entry() is the hugetlb callback for the early mprotect(PROT_NONE) PFN permission walk on x86.
The callback passes the decoded PFN to pfn_modify_allowed(). For a hugetlb callback, the pte pointer refers to a hugetlb entry. On architectures where hugetlb entries need huge_ptep_get(), reading that entry with ptep_get() can make the permission check use the wrong PFN.
Use huge_ptep_get() before decoding the hugetlb PFN.
Currently there is no path which can trigger a bug: huge_ptep_get() is a simple ptep_get() for x86, and the prot_none walk occurs only for x86.
So no need to backport - use the correct helper anyways.
...
mm/mprotect.c +1 -0
@@ -699,14 +699,20 @@ static int prot_none_pte_entry(pte_t *pte, unsigned long addr,
 		0 : -EACCES;
 }
 
+#ifdef CONFIG_HUGETLB_PAGE
 static int prot_none_hugetlb_entry(pte_t *pte, unsigned long hmask,
 				   unsigned long addr, unsigned long next,

mm/mprotect.c static int prot_none_pte_entry(pte_t *pte, unsigned long addr, · line 711

Quoted 10 lines

mm/mprotect.c +5 -3

 				   struct mm_walk *walk)
 {
-	return pfn_modify_allowed(pte_pfn(ptep_get(pte)),
-				  *(pgprot_t *)(walk->private)) ?
-		0 : -EACCES;
+	const pte_t entry = huge_ptep_get(walk->mm, addr, pte);
+
+	if (pfn_modify_allowed(pte_pfn(entry), *(pgprot_t *)(walk->private)))
+		return 0;
+	return -EACCESS;

"EACCES".

mm/mprotect.c static int prot_none_pte_entry(pte_t *pte, unsigned long addr, · line 715

Quoted 4 lines

mm/mprotect.c +3 -0

 }
+#else
+#define prot_none_hugetlb_entry	NULL
+#endif

Presumably your .config resulted in this change not being tested...

Dev Jain

author

2026-07-05 08:47 UTC #19 lore raw

Re: [PATCH v3 6/6] mm/mprotect: use huge_ptep_get() for hugetlb

Quoted 41 lines · Andrew Morton

Quoted 26 lines · On Fri, 3 Jul 2026 11:41:59 +0000 Dev Jain <[email protected]> wrote:
prot_none_hugetlb_entry() is the hugetlb callback for the early mprotect(PROT_NONE) PFN permission walk on x86.
The callback passes the decoded PFN to pfn_modify_allowed(). For a hugetlb callback, the pte pointer refers to a hugetlb entry. On architectures where hugetlb entries need huge_ptep_get(), reading that entry with ptep_get() can make the permission check use the wrong PFN.
Use huge_ptep_get() before decoding the hugetlb PFN.
Currently there is no path which can trigger a bug: huge_ptep_get() is a simple ptep_get() for x86, and the prot_none walk occurs only for x86.
So no need to backport - use the correct helper anyways.
...
mm/mprotect.c +1 -0
@@ -699,14 +699,20 @@ static int prot_none_pte_entry(pte_t *pte, unsigned long addr,
 		0 : -EACCES;
 }
 
+#ifdef CONFIG_HUGETLB_PAGE
 static int prot_none_hugetlb_entry(pte_t *pte, unsigned long hmask,
 				   unsigned long addr, unsigned long next,
mm/mprotect.c static int prot_none_pte_entry(pte_t *pte, unsigned long addr, · line 711
Quoted 10 lines
mm/mprotect.c +5 -3
 				   struct mm_walk *walk)
 {
-	return pfn_modify_allowed(pte_pfn(ptep_get(pte)),
-				  *(pgprot_t *)(walk->private)) ?
-		0 : -EACCES;
+	const pte_t entry = huge_ptep_get(walk->mm, addr, pte);
+
+	if (pfn_modify_allowed(pte_pfn(entry), *(pgprot_t *)(walk->private)))
+		return 0;
+	return -EACCESS;
"EACCES".

Quoted 6 lines

mm/mprotect.c static int prot_none_pte_entry(pte_t *pte, unsigned long addr, · line 715
Quoted 4 lines
mm/mprotect.c +3 -0
 }
+#else
+#define prot_none_hugetlb_entry	NULL
+#endif
Presumably your .config resulted in this change not being tested...

Thanks for folding in the fix!

On arm64, this entire path does not exist. The prot none pagewalk is only done on x86. Also before sending patches I do an LLM review and very surprisingly the "language" model did not catch a language issue ...

On the other thing by Sashiko, that looks wrong. There are existing huge_ptep_get callers not taking the lock. And, there won't be a torn read because we are using __ptep_get() instead of *ptep.

David Hildenbrand (Arm)

maintainer Acked-by on v3 6/6

2026-07-06 08:48 UTC #20 lore raw

Re: [PATCH v3 6/6] mm/mprotect: use huge_ptep_get() for hugetlb

In reply to Dev Jain

Quoted 13 lines · Dev Jain

prot_none_hugetlb_entry() is the hugetlb callback for the early mprotect(PROT_NONE) PFN permission walk on x86.
The callback passes the decoded PFN to pfn_modify_allowed(). For a hugetlb callback, the pte pointer refers to a hugetlb entry. On architectures where hugetlb entries need huge_ptep_get(), reading that entry with ptep_get() can make the permission check use the wrong PFN.
Use huge_ptep_get() before decoding the hugetlb PFN.
Currently there is no path which can trigger a bug: huge_ptep_get() is a simple ptep_get() for x86, and the prot_none walk occurs only for x86.

Quoted 6 lines

So no need to backport - use the correct helper anyways.
Fixes 42e4089c7890 ("x86/speculation/l1tf: Disallow non privileged high MMIO PROT_NONE mappings")
Reviewed-by Muchun Song <[email protected]>
Signed-off-by Dev Jain <[email protected]>
---

Acked-by David Hildenbrand (Arm) <[email protected]>

Signature · 3 lines

Cheers,

David

Andrew Morton

maintainer

2026-07-05 07:45 UTC #21 lore raw

In reply to Dev Jain

Quoted 10 lines · On Fri, 3 Jul 2026 11:41:53 +0000 Dev Jain <[email protected]> wrote:

There are various places which use ptep_get() to get the pte entry corresponding to a hugetlb folio. Some arches (like s390) have special handling to compute the pteval, so they provide huge_ptep_get(). Use this helper consistently.
Additionally, some code paths may provide huge_ptep_get with an unaligned address. This is a problem on arm64 (I checked other arches and it looks fine for them), which is fixed in patch 1. The fix is made to be
backport-friendly: the cleaner fix would be to perhaps pass the hstate to huge_ptep_get() - that is wider churn and we can do that later.

Thanks, I added this series to mm-new.

That means 7.2 will be released with these bugs unfixed, which may be a mistake. But without knowing the userspace impact of these bugs, I cannot make this call :(

Sashiko is worried about [6/6]:

	https://sashiko.dev/#/patchset/[email protected]

Will Deacon

maintainer

2026-07-21 17:18 UTC #22 lore raw

In reply to Dev Jain

Quoted 11 lines · Dev Jain

There are various places which use ptep_get() to get the pte entry corresponding to a hugetlb folio. Some arches (like s390) have special handling to compute the pteval, so they provide huge_ptep_get(). Use this helper consistently.
Additionally, some code paths may provide huge_ptep_get with an unaligned address. This is a problem on arm64 (I checked other arches and it looks fine for them), which is fixed in patch 1. The fix is made to be to huge_ptep_get() - that is wider churn and we can do that later.
[...]

Applied first patch to arm64 (for-next/fixes), thanks!

[1/6] arm64: make huge_ptep_get handled unaligned addresses

      https://git.kernel.org/arm64/c/9175a8c7cfe88

I'm hoping Andrew can drop this from the mm tree to avoid a duplicate, but I didn't hear back yet and I'd like to land the fix.

Cheers,

Signature · 5 lines

Will

https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev

Andrew Morton

maintainer

2026-07-21 20:36 UTC #23 lore raw

Quoted 13 lines · On Tue, 21 Jul 2026 18:18:38 +0100 Will Deacon <[email protected]> wrote:

Quoted 11 lines · Dev Jain
There are various places which use ptep_get() to get the pte entry corresponding to a hugetlb folio. Some arches (like s390) have special handling to compute the pteval, so they provide huge_ptep_get(). Use this helper consistently.
Additionally, some code paths may provide huge_ptep_get with an unaligned address. This is a problem on arm64 (I checked other arches and it looks fine for them), which is fixed in patch 1. The fix is made to be to huge_ptep_get() - that is wider churn and we can do that later.
[...]

Quoted 7 lines

Applied first patch to arm64 (for-next/fixes), thanks!
[1/6] arm64: make huge_ptep_get handled unaligned addresses
      https://git.kernel.org/arm64/c/9175a8c7cfe88
I'm hoping Andrew can drop this from the mm tree to avoid a duplicate, but I didn't hear back yet and I'd like to land the fix.

I can redo Dev's series to omit [1/6]. The patches apply that way, but there might be build-time or runtime issues running the other patches without [1/6] present, haven't looked.

Also, review indicates that the changelog requires updating
(https://lore.kernel.org/all/[email protected]/)
and I believe that Dev plans to do that.

IOW, it would be better to carry this in mm.git with your ack.

Do you plan to upstream this in 7.2-rcX? If so then I can hang onto this patch until it appears in mainline. Or something.

Dev Jain

author

2026-07-22 04:33 UTC #24 lore raw

Quoted 23 lines · Andrew Morton

Quoted 13 lines · On Tue, 21 Jul 2026 18:18:38 +0100 Will Deacon <[email protected]> wrote:
Quoted 11 lines · Dev Jain
There are various places which use ptep_get() to get the pte entry corresponding to a hugetlb folio. Some arches (like s390) have special handling to compute the pteval, so they provide huge_ptep_get(). Use this helper consistently.
Additionally, some code paths may provide huge_ptep_get with an unaligned address. This is a problem on arm64 (I checked other arches and it looks fine for them), which is fixed in patch 1. The fix is made to be to huge_ptep_get() - that is wider churn and we can do that later.
[...]
Quoted 7 lines
Applied first patch to arm64 (for-next/fixes), thanks!
[1/6] arm64: make huge_ptep_get handled unaligned addresses
      https://git.kernel.org/arm64/c/9175a8c7cfe88
I'm hoping Andrew can drop this from the mm tree to avoid a duplicate, but I didn't hear back yet and I'd like to land the fix.

Quoted 7 lines

I can redo Dev's series to omit [1/6]. The patches apply that way, but there might be build-time or runtime issues running the other patches without [1/6] present, haven't looked.
Also, review indicates that the changelog requires updating
(https://lore.kernel.org/all/[email protected]/)
and I believe that Dev plans to do that.

Oh I was banking on you to do that : )

@Will if you could edit the commit message with the following userspace visible effect:

Quoted 5 lines

IOW, it would be better to carry this in mm.git with your ack.
Do you plan to upstream this in 7.2-rcX? If so then I can hang onto this patch until it appears in mainline. Or something.

Will Deacon

maintainer

2026-07-22 11:52 UTC #25 lore raw

Quoted 9 lines · Dev Jain

@Will if you could edit the commit message with the following userspace visible effect:
"On systems where CONT_PTES != CONT_PMDS (meaning page size is 16K), we could collect excess a/d bit state, meaning extra work for the kernel. Even worse, we may iterate beyond the PTE table and dereference a garbage ptep pointer to access physical memory we don't own. Since the ptep pointer is a linear map address, we may run off the end of the linear map, dereference a VA not mapped into the kernel pgtables and cause kernel panic."

It's sitting on top of for-next/fixes so I can fold that in, thanks.

Will

Will Deacon

maintainer

2026-07-22 11:31 UTC #26 lore raw

In reply to Andrew Morton

Quoted 23 lines · Andrew Morton

Quoted 13 lines · On Tue, 21 Jul 2026 18:18:38 +0100 Will Deacon <[email protected]> wrote:
Quoted 11 lines · Dev Jain
There are various places which use ptep_get() to get the pte entry corresponding to a hugetlb folio. Some arches (like s390) have special handling to compute the pteval, so they provide huge_ptep_get(). Use this helper consistently.
Additionally, some code paths may provide huge_ptep_get with an unaligned address. This is a problem on arm64 (I checked other arches and it looks fine for them), which is fixed in patch 1. The fix is made to be to huge_ptep_get() - that is wider churn and we can do that later.
[...]
Quoted 7 lines
Applied first patch to arm64 (for-next/fixes), thanks!
[1/6] arm64: make huge_ptep_get handled unaligned addresses
      https://git.kernel.org/arm64/c/9175a8c7cfe88
I'm hoping Andrew can drop this from the mm tree to avoid a duplicate, but I didn't hear back yet and I'd like to land the fix.

Quoted 7 lines

I can redo Dev's series to omit [1/6]. The patches apply that way, but there might be build-time or runtime issues running the other patches without [1/6] present, haven't looked.
Also, review indicates that the changelog requires updating
(https://lore.kernel.org/all/[email protected]/)
and I believe that Dev plans to do that.

There's been no update for two weeks, so I wouldn't hold your breath!

Quoted 4 lines

IOW, it would be better to carry this in mm.git with your ack.
Do you plan to upstream this in 7.2-rcX? If so then I can hang onto this patch until it appears in mainline. Or something.

Yes, I'd like to get this (just this first patch!) in for -rc5 so I picked it into the arm64 fixes branch.

Will