Re: [PATCH 1/1] mm: fix out-of-bounds access and race in generic_access_phys

["David Hildenbrand (Arm)" <david@kernel.org>]

On 7/21/26 16:26, Ren Wei wrote:
> From: Luxiao Xu <rakukuip@gmail.com>
> 
> generic_access_phys() improperly validates the memory access range. It
> only validates the start address using follow_pfnmap_start() and then
> uses ioremap_prot() to map the entire requested length. This fails to
> verify if the access range stays within the VMA boundaries or if it
> crosses into adjacent physical/MMIO mappings, allowing out-of-bounds
> read or write access.
> 
> Furthermore, the previous implementation failed to handle partial
> progress semantics required by __access_remote_vm() and lacked
> necessary concurrency checks (retry logic) to prevent the use of
> stale mappings after releasing the PFNMAP lock.
> 
> Fix this by:
> - Processing memory access in page-sized chunks, ensuring every page
>   is validated within its VMA boundaries.
> - Introducing a retry mechanism to re-validate the PFN/protection
>   after mapping, ensuring safety against concurrent page table
>   modifications.
> - Returning the total number of bytes successfully copied to satisfy
>   the partial progress semantics of the access_process_vm
>   infrastructure.
> 
> Fixes: 9cb12d7b4cca ("mm/memory.c: actually remap enough memory")
> Cc: stable@vger.kernel.org
> Reported-by: Vega <vega@nebusec.ai>
> Assisted-by: Codex:gpt-5.4
> Signed-off-by: Luxiao Xu <rakukuip@gmail.com>
> Signed-off-by: Ren Wei <enjou1224z@gmail.com>


Hm, I wonder if it's responsibility of the callers to make sure that [addr,
addr+len) is actually within VMA bounds. Just like it's the callers
responsibility to ensure that "addr" falls within the VMA.

That makes the ->access() implementation harder to get wrong.

-- 
Cheers,

David