Re: [PATCH v2 1/1] mm/memory: constrain generic_access_phys() to page boundary

[Andrew Morton <akpm@linux-foundation.org>]

On Sat,  5 Sep 2026 22:12:17 +0800 Ren Wei <weir@nebusec.ai> wrote:

> generic_access_phys() improperly validates the memory access range: it
> only validates the start address using follow_pfnmap_start() and passes
> PAGE_ALIGN(len + offset) to ioremap_prot().
> 
> This poses two problems:
> 1. In PFNMAP VMAs, consecutive virtual pages are not guaranteed to be
>    physically contiguous, and individual PTEs may have different access
>    permissions or writability.
> 2. The mapping may cross VMA boundaries if len extends beyond vma->vm_end.
> 
> Since __access_remote_vm() already loops over the requested length and
> accesses normal (struct page) memory page-by-page, constrain the ->access()
> callback in __access_remote_vm() to at most the current page boundary.
> Because VMA boundaries are always page-aligned, this also ensures the
> access never exceeds the current VMA.
> 
> In generic_access_phys(), defensively clamp len to the page boundary as
> well, map only a single PAGE_SIZE via ioremap_prot(), and add a missing
> (resource_size_t) cast during PFN re-validation to avoid truncation on
> 32-bit PAE systems.

Thanks.

> Fixes: 9cb12d7b4cca ("mm/memory.c: actually remap enough memory")
> Cc: stable@vger.kernel.org

Why are we proposing a backport?  To do that we should provide
recipients with a clear description of the userspace-visible runtime
affects of this bug and I'm not seeing that in the changelog?