[PATCH v2] arm64: io: Reject non-user protection in ioremap_prot()

Zeng Heng posted 1 patch 2 weeks ago
arch/arm64/include/asm/io.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
[PATCH v2] arm64: io: Reject non-user protection in ioremap_prot()
Posted by Zeng Heng 2 weeks ago
From: Zeng Heng <zengheng4@huawei.com>

Mapping a stack-top page via /dev/mem with PROT_NONE and then
reading that process's /proc/<pid>/cmdline triggers a spurious WARN
in ioremap_prot() through generic_access_phys():

  WARNING: ./arch/arm64/include/asm/io.h:275 at generic_access_phys
  Call trace:
    generic_access_phys+0x1c8/0x228 (P)
    __access_remote_vm+0x2b4/0x398
    access_remote_vm+0x14/0x30
    get_mm_cmdline+0xf8/0x2a0
    proc_pid_cmdline_read+0x68/0x120

generic_access_phys() passes the protection derived from the user PTE
to ioremap_prot(). On arm64, a PROT_NONE mapping is represented by a
present-invalid PTE, so pte_present() still returns true and the
protection reaches ioremap_prot().

A PROT_NONE mapping does not have PTE_USER, causing the existing
WARN_ON_ONCE() in ioremap_prot() to fire even though this is a valid
user mapping. Execute-only mappings have the same issue and must not
be readable through this path either.

ioremap_prot() should therefore reject protection values without
PTE_USER without warning. This makes the access fail cleanly for
PROT_NONE and execute-only mappings while retaining the existing
user-protection contract.

Fixes: 8f098037139b ("arm64: io: Extract user memory type in ioremap_prot()")
Signed-off-by: Zeng Heng <zengheng4@huawei.com>
---
 arch/arm64/include/asm/io.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/include/asm/io.h b/arch/arm64/include/asm/io.h
index 21c8e400107c..31e67f6bd4a7 100644
--- a/arch/arm64/include/asm/io.h
+++ b/arch/arm64/include/asm/io.h
@@ -272,7 +272,8 @@ static inline void __iomem *ioremap_prot(phys_addr_t phys, size_t size,
 	pgprot_t prot;
 	ptval_t user_prot_val = pgprot_val(user_prot);
 
-	if (WARN_ON_ONCE(!(user_prot_val & PTE_USER)))
+	/* Reject PROT_NONE and exec-only */
+	if (!(user_prot_val & PTE_USER))
 		return NULL;
 
 	prot = __pgprot_modify(PAGE_KERNEL, PTE_ATTRINDX_MASK,
-- 
2.43.0
Re: [PATCH v2] arm64: io: Reject non-user protection in ioremap_prot()
Posted by Will Deacon 1 week ago
On Fri, 11 Sep 2026 09:58:59 +0800, Zeng Heng wrote:
> Mapping a stack-top page via /dev/mem with PROT_NONE and then
> reading that process's /proc/<pid>/cmdline triggers a spurious WARN
> in ioremap_prot() through generic_access_phys():
> 
>   WARNING: ./arch/arm64/include/asm/io.h:275 at generic_access_phys
>   Call trace:
>     generic_access_phys+0x1c8/0x228 (P)
>     __access_remote_vm+0x2b4/0x398
>     access_remote_vm+0x14/0x30
>     get_mm_cmdline+0xf8/0x2a0
>     proc_pid_cmdline_read+0x68/0x120
> 
> [...]

Applied to arm64 (for-next/fixes), thanks!

[1/1] arm64: io: Reject non-user protection in ioremap_prot()
      https://git.kernel.org/arm64/c/bb756b11ad63

Cheers,
-- 
Will

https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev
Re: [PATCH v2] arm64: io: Reject non-user protection in ioremap_prot()
Posted by Catalin Marinas 1 week, 2 days ago
On Fri, Sep 11, 2026 at 09:58:59AM +0800, Zeng Heng wrote:
> diff --git a/arch/arm64/include/asm/io.h b/arch/arm64/include/asm/io.h
> index 21c8e400107c..31e67f6bd4a7 100644
> --- a/arch/arm64/include/asm/io.h
> +++ b/arch/arm64/include/asm/io.h
> @@ -272,7 +272,8 @@ static inline void __iomem *ioremap_prot(phys_addr_t phys, size_t size,
>  	pgprot_t prot;
>  	ptval_t user_prot_val = pgprot_val(user_prot);
>  
> -	if (WARN_ON_ONCE(!(user_prot_val & PTE_USER)))
> +	/* Reject PROT_NONE and exec-only */
> +	if (!(user_prot_val & PTE_USER))
>  		return NULL;
>  
>  	prot = __pgprot_modify(PAGE_KERNEL, PTE_ATTRINDX_MASK,

Looks alright to me:

Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>

It would be good to get Sashiko's finding sorted out as well
(pre-existing issue). I reckon that should go in the core code.

-- 
Catalin
Re: [PATCH v2] arm64: io: Reject non-user protection in ioremap_prot()
Posted by Catalin Marinas 1 week, 2 days ago
On Wed, Sep 16, 2026 at 01:35:12PM +0100, Catalin Marinas wrote:
> It would be good to get Sashiko's finding sorted out as well
> (pre-existing issue). I reckon that should go in the core code.

Ah, that's getting fixed already:

https://lore.kernel.org/all/e06e28a46c2a176238f03b5740df0913e57c2861.1788842306.git.rakukuip@gmail.com/

-- 
Catalin
Re: [PATCH v2] arm64: io: Reject non-user protection in ioremap_prot()
Posted by Will Deacon 2 weeks ago
On Fri, Sep 11, 2026 at 09:58:59AM +0800, Zeng Heng wrote:
> From: Zeng Heng <zengheng4@huawei.com>
> 
> Mapping a stack-top page via /dev/mem with PROT_NONE and then
> reading that process's /proc/<pid>/cmdline triggers a spurious WARN
> in ioremap_prot() through generic_access_phys():
> 
>   WARNING: ./arch/arm64/include/asm/io.h:275 at generic_access_phys
>   Call trace:
>     generic_access_phys+0x1c8/0x228 (P)
>     __access_remote_vm+0x2b4/0x398
>     access_remote_vm+0x14/0x30
>     get_mm_cmdline+0xf8/0x2a0
>     proc_pid_cmdline_read+0x68/0x120
> 
> generic_access_phys() passes the protection derived from the user PTE
> to ioremap_prot(). On arm64, a PROT_NONE mapping is represented by a
> present-invalid PTE, so pte_present() still returns true and the
> protection reaches ioremap_prot().
> 
> A PROT_NONE mapping does not have PTE_USER, causing the existing
> WARN_ON_ONCE() in ioremap_prot() to fire even though this is a valid
> user mapping. Execute-only mappings have the same issue and must not
> be readable through this path either.
> 
> ioremap_prot() should therefore reject protection values without
> PTE_USER without warning. This makes the access fail cleanly for
> PROT_NONE and execute-only mappings while retaining the existing
> user-protection contract.
> 
> Fixes: 8f098037139b ("arm64: io: Extract user memory type in ioremap_prot()")
> Signed-off-by: Zeng Heng <zengheng4@huawei.com>
> ---
>  arch/arm64/include/asm/io.h | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm64/include/asm/io.h b/arch/arm64/include/asm/io.h
> index 21c8e400107c..31e67f6bd4a7 100644
> --- a/arch/arm64/include/asm/io.h
> +++ b/arch/arm64/include/asm/io.h
> @@ -272,7 +272,8 @@ static inline void __iomem *ioremap_prot(phys_addr_t phys, size_t size,
>  	pgprot_t prot;
>  	ptval_t user_prot_val = pgprot_val(user_prot);
>  
> -	if (WARN_ON_ONCE(!(user_prot_val & PTE_USER)))
> +	/* Reject PROT_NONE and exec-only */
> +	if (!(user_prot_val & PTE_USER))
>  		return NULL;

I was initially worried about getting an invalid PTE here which happened
to have PTE_USER set (e.g. as part of a swap entry), but it looks like
follow_pfnmap_start() returns -EINVAL if the PTE isn't present.

So I think this is ok, but I'll wait to see what Catalin thinks.

Will