Re: [PATCH v3] arm64: mm: fix pass user prot to ioremap_prot in generic_access_phys
From: Will Deacon <will@kernel.org>
Date: 2026-02-03 09:23:10
Also in:
linux-mm
On Tue, Feb 03, 2026 at 11:38:15AM +0800, Jinjiang Tu wrote:
在 2026/2/2 22:55, Will Deacon 写道:quoted
On Fri, Jan 30, 2026 at 03:38:07PM +0800, Jinjiang Tu wrote:quoted
Here is a syzkaller error log: [0000000020ffc000] pgd=080000010598d403, p4d=080000010598d403, pud=0800000125ddb403, pmd=080000007833c403, pte=01608000007fcfcf Unable to handle kernel read from unreadable memory at virtual address ffff80008ea89000 KASAN: probably user-memory-access in range [0x0000000475448000-0x0000000475448007] Mem abort info: ESR = 0x000000009600000f EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x0f: level 3 permission fault Data abort info: ISV = 0, ISS = 0x0000000f, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 swapper pgtable: 4k pages, 48-bit VAs, pgdp=00000001244aa000 [ffff80008ea89000] pgd=100000013ffff403, p4d=100000013ffff403, pud=100000013fffe403, pmd=100000010a453403, pte=01608000007fcfcf Internal error: Oops: 000000009600000f [#1] SMP Modules linked in: team CPU: 1 PID: 10840 Comm: syz.9.83 Kdump: loaded Tainted: G Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015 pstate: 20400005 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : __memcpy_fromio+0x80/0xf8 lr : generic_access_phys+0x20c/0x2b8 sp : ffff8000a0507960 x29: ffff8000a0507960 x28: 1ffff000140a0f44 x27: ffff00003833cfe0 x26: 0000000000000000 x25: 0000000000001000 x24: 0010000000000001 x23: ffff80008ea89000 x22: ffff00004ea63000 x21: 0000000000001000 x20: ffff80008ea89000 x19: ffff00004ea62000 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: ffff8000806f1e3c x14: ffff8000806f1d44 x13: 0000000041b58ab3 x12: ffff7000140a0f23 x11: 1ffff000140a0f22 x10: ffff7000140a0f22 x9 : ffff800080579d24 x8 : 0000000000000004 x7 : 0000000000000003 x6 : 0000000000000001 x5 : ffff8000a0507910 x4 : ffff7000140a0f22 x3 : dfff800000000000 x2 : 0000000000001000 x1 : ffff80008ea89000 x0 : ffff00004ea62000 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 invoke_syscall+0x68/0x1a0 el0_svc_common.constprop.0+0x11c/0x150 do_el0_svc+0x38/0x50 el0_svc+0x50/0x258 el0t_64_sync_handler+0xc0/0xc8 el0t_64_sync+0x1a4/0x1a8 Code: 91002339 aa1403f7 8b190276 d503201f (f94002f8) The local syzkaller first maps I/O address from /dev/mem to userspace, overiding the stack vma with MAP_FIXED flag. As a result, when reading /proc/$pid/environ, generic_access_phys() is called to access the region, which triggers a PAN permission-check fault and causes a kernel access fault. The root cause is that generic_access_phys() passes a user pte to ioremap_prot(), the user pte sets PTE_USER and PTE_NG bits. Consequently, any subsequent kernel-mode access to the remapped address raises a fault. To fix it, define arch_mk_kernel_prot() to convert user prot to kernel prot for arm64, and call arch_mk_kernel_prot() in generic_access_phys(), so that a user prot is passed to ioremap_prot(). Fixes: 893dea9ccd08 ("arm64: Add HAVE_IOREMAP_PROT support") Signed-off-by: Zeng Heng <redacted> Signed-off-by: Jinjiang Tu <redacted> --- Changes in v3: * arch_mk_kernel_prot() always grant read/write permissions. arch/arm64/include/asm/io.h | 8 ++++++++ mm/memory.c | 12 +++++++++++- 2 files changed, 19 insertions(+), 1 deletion(-)diff --git a/arch/arm64/include/asm/io.h b/arch/arm64/include/asm/io.h index 83e03abbb2ca..fe3040d59119 100644 --- a/arch/arm64/include/asm/io.h +++ b/arch/arm64/include/asm/io.h@@ -267,6 +267,14 @@ int arm64_ioremap_prot_hook_register(const ioremap_prot_hook_t hook); #define ioremap_prot ioremap_prot +#define arch_mk_kernel_prot arch_mk_kernel_prot +static inline pgprot_t arch_mk_kernel_prot(pgprot_t user_prot) +{ + ptdesc_t mem_type = pgprot_val(user_prot) & PTE_ATTRINDX_MASK; + + return __pgprot_modify(PAGE_KERNEL, PTE_ATTRINDX_MASK, mem_type); +}Do we really need another arch helper here?For arc, powerpc, ioremap_prot() simply copy the user pte prot to the kernel page table too. So maybe we should fix for the two archs too, and we should define a arch helper here. But I'm not familiar with them.
My point is that we already have the helper: ioremap_prot(). Just fix that for arm64 and cc the other arch maintainers if you're not sure how to fix it for them. What we don't need to do is add an additional helper. Will