All of lore.kernel.org
 help / color / mirror / Atom feed
From: Catalin Marinas <catalin.marinas@arm.com>
To: Will Deacon <will@kernel.org>
Cc: linux-arm-kernel@lists.infradead.org,
	Zeng Heng <zengheng4@huawei.com>,
	Jinjiang Tu <tujinjiang@huawei.com>,
	Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH 2/2] arm64: io: Extract user memory type in ioremap_prot()
Date: Tue, 24 Feb 2026 08:10:58 +0000	[thread overview]
Message-ID: <aZ1dEsub9133Qv1e@arm.com> (raw)
In-Reply-To: <20260223221012.31962-3-will@kernel.org>

On Mon, Feb 23, 2026 at 10:10:11PM +0000, Will Deacon wrote:
> The only caller of ioremap_prot() outside of the generic ioremap()
> implementation is generic_access_phys(), which passes a 'pgprot_t' value
> determined from the user mapping of the target 'pfn' being accessed by
> the kernel. On arm64, the 'pgprot_t' contains all of the non-address
> bits from the pte, including the permission controls, and so we end up
> returning a new user mapping from ioremap_prot() which faults when
> accessed from the kernel on systems with PAN:
> 
>   | Unable to handle kernel read from unreadable memory at virtual address ffff80008ea89000
>   | ...
>   | Call trace:
>   |   __memcpy_fromio+0x80/0xf8
>   |   generic_access_phys+0x20c/0x2b8
>   |   __access_remote_vm+0x46c/0x5b8
>   |   access_remote_vm+0x18/0x30
>   |   environ_read+0x238/0x3e8
>   |   vfs_read+0xe4/0x2b0
>   |   ksys_read+0xcc/0x178
>   |   __arm64_sys_read+0x4c/0x68
> 
> Extract only the memory type from the user 'pgprot_t' in ioremap_prot()
> and assert that we're being passed a user mapping, to protect us against
> any changes in future that may require additional handling. To avoid
> falsely flagging users of ioremap(), provide our own ioremap() macro
> which simply wraps __ioremap_prot().
> 
> Cc: Zeng Heng <zengheng4@huawei.com>
> Cc: Jinjiang Tu <tujinjiang@huawei.com>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Fixes: 893dea9ccd08 ("arm64: Add HAVE_IOREMAP_PROT support")
> Reported-by: Jinjiang Tu <tujinjiang@huawei.com>
> Signed-off-by: Will Deacon <will@kernel.org>

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


  reply	other threads:[~2026-02-24  8:11 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-23 22:10 [PATCH 0/2] arm64: Fix syzkaller splat in ioremap_prot() Will Deacon
2026-02-23 22:10 ` [PATCH 1/2] arm64: io: Rename ioremap_prot() to __ioremap_prot() Will Deacon
2026-02-24  8:10   ` Catalin Marinas
2026-02-23 22:10 ` [PATCH 2/2] arm64: io: Extract user memory type in ioremap_prot() Will Deacon
2026-02-24  8:10   ` Catalin Marinas [this message]
2026-02-26  0:06 ` [PATCH 0/2] arm64: Fix syzkaller splat " Will Deacon

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=aZ1dEsub9133Qv1e@arm.com \
    --to=catalin.marinas@arm.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=tujinjiang@huawei.com \
    --cc=will@kernel.org \
    --cc=zengheng4@huawei.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.