Re: [PATCH] mm: disallow ioremap'ing ordinary RAM in generic_access_phys()

[Lance Yang <lance.yang@linux.dev>]

On Tue, Oct 13, 2026 at 01:41:24PM +0200, David Hildenbrand (Arm) wrote:
>generic_access_phys() can end up getting called on CoW PFNMAP mappings,
>resulting in it trying to ioremap anonymous folios, which especially
>the x86 code doesn't enjoy, and which is in general just odd/wrong.
>
>E.g., with a CoW mapping of a PCI BAR:
>
>ioremap on RAM at 0x0000000045623000 - 0x0000000045623fff
>  WARNING: arch/x86/mm/ioremap.c:216 at __ioremap_caller.isra.0+0x4c2/0x5f0
>  Call Trace:
>   generic_access_phys+0x130/0x4d0 mm/memory.c:7178
>   kernfs_vma_access+0x1ce/0x280 fs/kernfs/file.c:437
>   __access_remote_vm+0x58f/0x890 mm/memory.c:7256
>   mem_rw+0x2a1/0x670 fs/proc/base.c:912
>
>But more generically, we should disallow access to anything that looks
>like ordinary RAM in the system: including allocating memory (e.g.,
>alloc_pages) and mapping them in a VM_PFNMAP.
>
>For pages with an online memmap, allow only pages marked as reserved
>(PageReserved). This also includes memblock allocations, however,
>distinguishing them from other MMIO is tricky, and nobody should really
>be mapping them in a PFNMAP (except someone abusing /dev/mem, which we
>do not care about).
>
>So only allow access if there is no online memmap, or if the pages are
>marked reserved. Reject other pages with -EINVAL.
>
>Note that, just like other pfn_to_online_page() users, we won't care about
>concurrent memory offlining; mapping memory that can concurrently get
>offlined is highly dubious.
>
>Reported-by: syzbot+49b1021becba70c1f3f6@syzkaller.appspotmail.com
>Closes: https://syzkaller.appspot.com/bug?extid=49b1021becba70c1f3f6
>Reported-by: Nguyen Ngoc Thang <ngocthang2710.1999@gmail.com>
>Closes: https://lore.kernel.org/r/20261001152524.171115-1-ngocthang2710.1999@gmail.com/
>Fixes: 28b2ee20c7cb ("access_process_vm device memory infrastructure")
>Cc: stable@vger.kernel.org
>Signed-off-by: David Hildenbrand (Arm) <david@kernel.org>
>---

Nice work!

Tested-by: Lance Yang <lance.yang@linux.dev>