Re: [PATCH 6.12 1/1] arm64: io: correct user memory type in ioremap_prot()

[Catalin Marinas <catalin.marinas@arm.com>]

On Wed, May 27, 2026 at 11:01:04AM +0800, Xiangyu Chen wrote:
> On 5/21/26 01:01, Catalin Marinas wrote:
> > On Wed, May 20, 2026 at 05:13:37PM +0800, Xiangyu Chen wrote:
> > > generic_access_phys() passes a 'pgprot_t' value determined from the
> > > user mapping of the target 'pfn' being accessed by the kernel.
> > > On arm64, this 'pgprot_t' contains all non-address bits from the pte,
> > > including user permission controls (PTE_USER).
> > > 
> > > When a process attempts to read the target memory via cross-process
> > > subsystems (such as reading /proc/<pid>/mem or via ptrace), the kernel
> > > re-maps this memory using ioremap_prot(). Since the PTE_USER bit is
> > > incorrectly preserved in the temporary kernel-space mapping, it triggers
> > > a level 3 permission fault on systems with PAN (Privileged Access Never)
> > > enabled, resulting in an immediate kernel panic.
> > > 
> > > Upstream already fixed this issue in
> > > commit: 8f098037139b ("arm64: io: Extract user memory type in ioremap_prot()")
> > > 
> > > Directly porting the upstream patch's macro changes inside <asm/io.h>
> > > creates circular build dependencies due to the architecture-specific
> > > GENERIC_IOREMAP refactoring introduced in the stable kernel lifecycle.
> > > 
> > > To bypass header dependency traps safely, this backport confines the fix
> > > entirely inside the implementation layer of arch/arm64/mm/ioremap.c:
> > > 1. It uses pgprot_val() to safely unpack page properties into a pteval_t mask.
> > > 2. It introduces a targeted safety check (if (prot_val & PTE_USER)) to
> > >     selectively strip away volatile user permission parameters.
> > > 3. It maps the memory through pure kernel attributes, leaving standard
> > >     peripheral device drivers completely unaffected.
> > > 
> > > Tested-by: QEMU ARM64 (Cortex-A55, CONFIG_ARM64_PAN=y, /proc/<pid>/mem read)
> > > Fixes: 893dea9ccd08 ("arm64: Add HAVE_IOREMAP_PROT support")
> > > Signed-off-by: Xiangyu Chen <xiangyu.chen@windriver.com>
> >
> > Instead of re-implementing this, could we cherry-pick the prior commit
> > renaming ioremap_prot() to __ioremap_prot() throughout arm64? It's not a
> > straightforward cherry-pick since we changed the prot arg from unsigned
> > long to pgprot_t (across multiple architectures), but with some minor
> > tweaks we can get the patch below. After this, 8f098037139b should apply
> > (hopefully unmodified). Please give it a try:
> 
> Thanks for your suggestion.
> 
> After reviewing the code, it appears we cannot directly backport commit
> f6bf47ab32e0 ("arm64: io: Rename ioremap_prot() to __ioremap_prot()") to
> older stable kernels. This is because commit f6bf47ab32e0 depends on commit
> 86758b504864 ("mm/ioremap: pass pgprot_t to ioremap_prot() instead of
> unsigned long").

My proposed backport of f6bf47ab32e0 took care of using unsigned long
instead of pgprot_t since the dependencies get too complicated. Could
you try my backport of f6bf47ab32e0 together with cherry-picking
8f098037139b. The latter may need some adjustment of pgprot_t as well
but at least the final form will look fairly similar to upstream.

-- 
Catalin