From: "David Hildenbrand (Arm)" <david@kernel.org>
To: Andrew Morton <akpm@linux-foundation.org>,
Lorenzo Stoakes <ljs@kernel.org>,
"Liam R. Howlett" <liam@infradead.org>,
Vlastimil Babka <vbabka@kernel.org>,
Mike Rapoport <rppt@kernel.org>,
Suren Baghdasaryan <surenb@google.com>,
Michal Hocko <mhocko@suse.com>,
Benjamin Herrensmidt <benh@kernel.crashing.org>,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
Rik van Riel <riel@redhat.com>,
Nguyen Ngoc Thang <ngocthang2710.1999@gmail.com>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
syzbot+49b1021becba70c1f3f6@syzkaller.appspotmail.com,
stable@vger.kernel.org,
"David Hildenbrand (Arm)" <david@kernel.org>
Subject: [PATCH] mm: disallow ioremap'ing ordinary RAM in generic_access_phys()
Date: Tue, 13 Oct 2026 13:41:24 +0200 [thread overview]
Message-ID: <20261013-generic_access_phys-v1-1-b3963ef76e37@kernel.org> (raw)
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>
---
I went back and forth 10 times and concluded that using PageReserved
should be the right thing to check for now.
---
mm/memory.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/mm/memory.c b/mm/memory.c
index 1f5d5f7d39cd2..5d9f757a00073 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -7226,6 +7226,7 @@ int generic_access_phys(struct vm_area_struct *vma, unsigned long addr,
resource_size_t phys_addr;
pgprot_t prot = __pgprot(0);
void __iomem *maddr;
+ struct page *page;
int offset = offset_in_page(addr);
int ret = -EINVAL;
bool writable;
@@ -7240,6 +7241,19 @@ int generic_access_phys(struct vm_area_struct *vma, unsigned long addr,
retry:
if (follow_pfnmap_start(&args))
return -EINVAL;
+
+ /*
+ * Reject anything that looks like ordinary RAM, including anonymous
+ * folios in CoW mappings or allocated kernel memory. Note that we
+ * cannot distinguish memblock allocations from non-RAM reliably, so
+ * we cannot easily reject them here.
+ */
+ page = pfn_to_online_page(args.pfn);
+ if (page && !PageReserved(page)) {
+ follow_pfnmap_end(&args);
+ return -EINVAL;
+ }
+
prot = args.pgprot;
phys_addr = (resource_size_t)args.pfn << PAGE_SHIFT;
writable = args.writable;
---
base-commit: 634cbf5b794b734c78631b92e381cfc85f357bbe
change-id: 20261009-generic_access_phys-0f3e0806305d
--
Cheers,
David
next reply other threads:[~2026-10-13 11:41 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-13 11:41 David Hildenbrand (Arm) [this message]
2026-10-13 12:29 ` [PATCH] mm: disallow ioremap'ing ordinary RAM in generic_access_phys() Lorenzo Stoakes (ARM)
2026-10-13 15:56 ` Mike Rapoport
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20261013-generic_access_phys-v1-1-b3963ef76e37@kernel.org \
--to=david@kernel.org \
--cc=a.p.zijlstra@chello.nl \
--cc=akpm@linux-foundation.org \
--cc=benh@kernel.crashing.org \
--cc=liam@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ljs@kernel.org \
--cc=mhocko@suse.com \
--cc=ngocthang2710.1999@gmail.com \
--cc=riel@redhat.com \
--cc=rppt@kernel.org \
--cc=stable@vger.kernel.org \
--cc=surenb@google.com \
--cc=syzbot+49b1021becba70c1f3f6@syzkaller.appspotmail.com \
--cc=vbabka@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox