[PATCH] proc/task_mmu: handle special PMDs in clear_refs and pagemap

[PATCH] proc/task_mmu: handle special PMDs in clear_refs and pagemap

[Gregory Price]

mshv_vtl_low can install a special PMD from a PFN supplied in the mmap file
offset.  That PFN need not have a memmap entry.  Reading /proc/PID/pagemap
or writing /proc/PID/clear_refs for such a mapping oopses the kernel.

With a test driver mapping the PFN at the 1 TiB mark:

  echo 1 > /proc/self/clear_refs

  BUG: unable to handle page fault for address: fffffb5b80000008
  #PF: supervisor read access in kernel mode
  #PF: error_code(0x0000) - not-present page
  RIP: 0010:clear_refs_pte_range+0xb1/0x1e0
  Call Trace:
   walk_pgd_range+0x50a/0xad0
   __walk_page_range+0x6a/0x1d0
   walk_page_range_mm_unsafe+0x193/0x230
   clear_refs_write+0x18e/0x3f0

  pread(pagemap_fd, buf, 512 * 8, addr / PAGE_SIZE * 8)

  BUG: unable to handle page fault for address: fffff57840000008
  RIP: 0010:pagemap_pmd_range+0x3cf/0x6b0
  Call Trace:
   walk_pgd_range+0x50a/0xad0
   __walk_page_range+0x6a/0x1d0
   walk_page_range_mm_unsafe+0x193/0x230
   pagemap_read+0x1dc/0x350

clear_refs_pte_range() passes the PMD to pmd_folio(), while
pagemap_pmd_range_thp() uses pmd_page() followed by page_folio().

Both paths assume the PFN has a struct page and dereference bad address.

Use vm_normal_folio_pmd() and vm_normal_page_pmd() so clear_refs skips
folio operations and pagemap skips folio-derived flags for special PMDs.
This matches the PTE paths, which already use vm_normal_folio() and
vm_normal_page().

User-facing notes:
 - Pagemap still reports PM_PRESENT and the PFN to a CAP_SYS_ADMIN reader.

 - For a special PMD backed by a valid memmap entry and for the huge
   zero PMD, PM_FILE changes from set to clear.

 - PM_MMAP_EXCLUSIVE is already clear in both cases.

 - The output for an anonymous THP is unchanged.

Tested in QEMU with the test driver on broken and fixed kernels.  Both proc
operations oops before the fix and return 0 after it.

Reported-by: sashiko-bot <sashiko-bot@kernel.org>
Closes: https://sashiko.dev/#/patchset/20260912034833.2952750-1-gourry%40gourry.net
Fixes: 3c8e44c9b369 ("mm: mark special bits for huge pfn mappings when inject")
Cc: <stable@vger.kernel.org> # v6.19+
Assisted-by: LLM
Signed-off-by: Gregory Price <gourry@gourry.net>
---
 fs/proc/task_mmu.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
index 24425e230895..501cd038b4e4 100644
--- a/fs/proc/task_mmu.c
+++ b/fs/proc/task_mmu.c
@@ -1671,7 +1671,9 @@ static int clear_refs_pte_range(pmd_t *pmd, unsigned long addr,
 		if (!pmd_present(*pmd))
 			goto out;
 
-		folio = pmd_folio(*pmd);
+		folio = vm_normal_folio_pmd(vma, addr, *pmd);
+		if (!folio)
+			goto out;
 
 		/* Clear accessed and referenced bits. */
 		pmdp_test_and_clear_young(vma, addr, pmd);
@@ -1991,7 +1993,7 @@ static int pagemap_pmd_range_thp(pmd_t *pmdp, unsigned long addr,
 		goto populate_pagemap;
 
 	if (pmd_present(pmd)) {
-		page = pmd_page(pmd);
+		page = vm_normal_page_pmd(vma, addr, pmd);
 
 		flags |= PM_PRESENT;
 		if (pmd_soft_dirty(pmd))
-- 
2.55.0

Re: [PATCH] proc/task_mmu: handle special PMDs in clear_refs and pagemap

[Andrew Morton]

On Sat, 12 Sep 2026 08:28:22 -0400 Gregory Price <gourry@gourry.net> wrote:

> mshv_vtl_low can install a special PMD from a PFN supplied in the mmap file
> offset.  That PFN need not have a memmap entry.  Reading /proc/PID/pagemap
> or writing /proc/PID/clear_refs for such a mapping oopses the kernel.
> 
> With a test driver mapping the PFN at the 1 TiB mark:
> 
>   echo 1 > /proc/self/clear_refs
> 
>   BUG: unable to handle page fault for address: fffffb5b80000008
>   #PF: supervisor read access in kernel mode
>   #PF: error_code(0x0000) - not-present page
>   RIP: 0010:clear_refs_pte_range+0xb1/0x1e0
>   Call Trace:
>    walk_pgd_range+0x50a/0xad0
>    __walk_page_range+0x6a/0x1d0
>    walk_page_range_mm_unsafe+0x193/0x230
>    clear_refs_write+0x18e/0x3f0
> 
>   pread(pagemap_fd, buf, 512 * 8, addr / PAGE_SIZE * 8)
> 
>   BUG: unable to handle page fault for address: fffff57840000008
>   RIP: 0010:pagemap_pmd_range+0x3cf/0x6b0
>   Call Trace:
>    walk_pgd_range+0x50a/0xad0
>    __walk_page_range+0x6a/0x1d0
>    walk_page_range_mm_unsafe+0x193/0x230
>    pagemap_read+0x1dc/0x350
> 
> clear_refs_pte_range() passes the PMD to pmd_folio(), while
> pagemap_pmd_range_thp() uses pmd_page() followed by page_folio().
> 
> Both paths assume the PFN has a struct page and dereference bad address.
> 
> Use vm_normal_folio_pmd() and vm_normal_page_pmd() so clear_refs skips
> folio operations and pagemap skips folio-derived flags for special PMDs.
> This matches the PTE paths, which already use vm_normal_folio() and
> vm_normal_page().
> 
> Fixes: 3c8e44c9b369 ("mm: mark special bits for huge pfn mappings when inject")
> Cc: <stable@vger.kernel.org> # v6.19+

Why cc:stable?  Is a crafted test driver the only way of hitting this?


> --- a/fs/proc/task_mmu.c
> +++ b/fs/proc/task_mmu.c
> @@ -1671,7 +1671,9 @@ static int clear_refs_pte_range(pmd_t *pmd, unsigned long addr,
>  		if (!pmd_present(*pmd))
>  			goto out;
>  
> -		folio = pmd_folio(*pmd);
> +		folio = vm_normal_folio_pmd(vma, addr, *pmd);
> +		if (!folio)
> +			goto out;
>  
>  		/* Clear accessed and referenced bits. */
>  		pmdp_test_and_clear_young(vma, addr, pmd);
> @@ -1991,7 +1993,7 @@ static int pagemap_pmd_range_thp(pmd_t *pmdp, unsigned long addr,
>  		goto populate_pagemap;
>  
>  	if (pmd_present(pmd)) {
> -		page = pmd_page(pmd);
> +		page = vm_normal_page_pmd(vma, addr, pmd);
>  
>  		flags |= PM_PRESENT;
>  		if (pmd_soft_dirty(pmd))

Re: [PATCH] proc/task_mmu: handle special PMDs in clear_refs and pagemap

[Gregory Price]

On Mon, Sep 14, 2026 at 09:49:10PM -0700, Andrew Morton wrote:
> On Sat, 12 Sep 2026 08:28:22 -0400 Gregory Price <gourry@gourry.net> wrote:
> 
> > mshv_vtl_low can install a special PMD from a PFN supplied in the mmap file
> > offset.  That PFN need not have a memmap entry.  Reading /proc/PID/pagemap
> > or writing /proc/PID/clear_refs for such a mapping oopses the kernel.
> > 
> > With a test driver mapping the PFN at the 1 TiB mark:
> > 
> >   echo 1 > /proc/self/clear_refs
> > 
> >   BUG: unable to handle page fault for address: fffffb5b80000008
> >   #PF: supervisor read access in kernel mode
> >   #PF: error_code(0x0000) - not-present page
> >   RIP: 0010:clear_refs_pte_range+0xb1/0x1e0
> >   Call Trace:
> >    walk_pgd_range+0x50a/0xad0
> >    __walk_page_range+0x6a/0x1d0
> >    walk_page_range_mm_unsafe+0x193/0x230
> >    clear_refs_write+0x18e/0x3f0
> > 
> >   pread(pagemap_fd, buf, 512 * 8, addr / PAGE_SIZE * 8)
> > 
> >   BUG: unable to handle page fault for address: fffff57840000008
> >   RIP: 0010:pagemap_pmd_range+0x3cf/0x6b0
> >   Call Trace:
> >    walk_pgd_range+0x50a/0xad0
> >    __walk_page_range+0x6a/0x1d0
> >    walk_page_range_mm_unsafe+0x193/0x230
> >    pagemap_read+0x1dc/0x350
> > 
> > clear_refs_pte_range() passes the PMD to pmd_folio(), while
> > pagemap_pmd_range_thp() uses pmd_page() followed by page_folio().
> > 
> > Both paths assume the PFN has a struct page and dereference bad address.
> > 
> > Use vm_normal_folio_pmd() and vm_normal_page_pmd() so clear_refs skips
> > folio operations and pagemap skips folio-derived flags for special PMDs.
> > This matches the PTE paths, which already use vm_normal_folio() and
> > vm_normal_page().
> > 
> > Fixes: 3c8e44c9b369 ("mm: mark special bits for huge pfn mappings when inject")
> > Cc: <stable@vger.kernel.org> # v6.19+
> 
> Why cc:stable?  Is a crafted test driver the only way of hitting this?
> 

Technically reachable via mshv_vtl_low, so i tagged it stable.

It's hard to make a judgment call on some of these - so I err on the
side of backporting.  Feel free to drop stable if you think it's not
worth it.

~Gregory

Re: [PATCH] proc/task_mmu: handle special PMDs in clear_refs and pagemap

[Andrew Morton]

On Tue, 15 Sep 2026 01:19:50 -0400 Gregory Price <gourry@gourry.net> wrote:

> > > Fixes: 3c8e44c9b369 ("mm: mark special bits for huge pfn mappings when inject")
> > > Cc: <stable@vger.kernel.org> # v6.19+
> > 
> > Why cc:stable?  Is a crafted test driver the only way of hitting this?
> > 
> 
> Technically reachable via mshv_vtl_low, so i tagged it stable.

I have no idea what this means, but I pasted it in ;)

> It's hard to make a judgment call on some of these - so I err on the
> side of backporting.  Feel free to drop stable if you think it's not
> worth it.

I retained the cc:stable.  It's disturbing to leave known bugs in there
because we *think* nobody can reach them.  What if we're wrong about that?