From: "Lorenzo Stoakes (ARM)" <ljs@kernel.org>
To: "David Hildenbrand (Arm)" <david@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.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>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
syzbot+49b1021becba70c1f3f6@syzkaller.appspotmail.com,
stable@vger.kernel.org
Subject: Re: [PATCH] mm: disallow ioremap'ing ordinary RAM in generic_access_phys()
Date: Tue, 13 Oct 2026 13:29:58 +0100 [thread overview]
Message-ID: <as4aeYkqZywLo4Gx@gremlin> (raw)
In-Reply-To: <20261013-generic_access_phys-v1-1-b3963ef76e37@kernel.org>
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.
Ugh god.
>
> 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.
Yes.
>
> 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).
Yeah I guess we shouldn't try too hard for weird edge cases, or at least
can revisit it later potentially.
>
> So only allow access if there is no online memmap, or if the pages are
> marked reserved. Reject other pages with -EINVAL.
Seems reasonable overall.
>
> 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.
Yeah sounds like the user would be doing something crazy in this case,
therefore their problem!
>
> 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>
LGTM so:
Reviewed-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>
> ---
> I went back and forth 10 times and concluded that using PageReserved
> should be the right thing to check for now.
It seems the sensible choice, yes. And locally, AI review agrees with you, FWIW!
--
Cheers, Lorenzo
next prev parent reply other threads:[~2026-10-13 12:30 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-13 11:41 David Hildenbrand (Arm)
2026-10-13 12:29 ` Lorenzo Stoakes (ARM) [this message]
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=as4aeYkqZywLo4Gx@gremlin \
--to=ljs@kernel.org \
--cc=a.p.zijlstra@chello.nl \
--cc=akpm@linux-foundation.org \
--cc=benh@kernel.crashing.org \
--cc=david@kernel.org \
--cc=liam@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.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
all inboxes | Powered by JetHome®