From: "Ritesh Harjani (IBM)" <ritesh.list@gmail.com>
To: linuxppc-dev@lists.ozlabs.org
Cc: Madhavan Srinivasan <maddy@linux.ibm.com>,
Venkat Rao Bagalkote <venkat88@linux.ibm.com>,
linux-kernel@vger.kernel.org, chleroy@kernel.org,
Michael Ellerman <mpe@ellerman.id.au>,
Nicholas Piggin <npiggin@gmail.com>,
Shrikanth Hegde <sshegde@linux.ibm.com>,
Hari Bathini <hbathini@linux.ibm.com>,
"Ritesh Harjani (IBM)" <ritesh.list@gmail.com>
Subject: [PATCHv2 2/3] powerpc/execmem: Allocate kprobes insn pages from the modules area on book3s/32
Date: Fri, 13 Nov 2026 18:01:37 +0530 [thread overview]
Message-ID: <82c4973addebd82923c460cb44221f5b76146afe.1794572365.git.ritesh.list@gmail.com> (raw)
In-Reply-To: <cover.1794572365.git.ritesh.list@gmail.com>
On book3s/32, a kprobe on an instruction that can't be emulated and has
to be single stepped out of line, crashes the kernel. For e.g. with the
following cmds...
~> echo 9 > /proc/sys/kernel/printk
~> mount -t debugfs debugfs /sys/kernel/debug
~> echo 'p:wx filldir64+0xb8' > /sys/kernel/debug/tracing/kprobe_events
~> echo 1 > /sys/kernel/debug/tracing/events/kprobes/wx/enable
~> echo 1 > /sys/kernel/debug/tracing/events/kprobes/enable
...we can see the following crash:
kernel tried to execute exec-protected page (f101a008) - exploit attempt? (uid: 0)
BUG: Unable to handle kernel instruction fetch
Faulting instruction address: 0xc02b919c
Vector: 400 (Instruction Access) at [f19a9d60]
pc: c02b919c: filldir64+0xb8/0x2dc
lr: c02b9148: filldir64+0x64/0x2dc
sp: f19a9e20
msr: 10029032
current = 0xc112e900
pid = 102, comm = ls
enter ? for help
[f19a9e20] c1a8d420 (unreliable)
[f19a9e50] c02e4074 dcache_readdir+0x208/0x2a8
[f19a9e90] c02b8c5c iterate_dir+0x88/0x1fc
[f19a9ec0] c02b96e0 sys_getdents64+0x88/0x198
[f19a9f10] c0014400 system_call_exception+0xf8/0x20c
[f19a9f30] c00191ac ret_from_syscall+0x0/0x2c
---- Exception: c00 (System Call) at a7596164
SP (af802310) is in userspace
This happens because on book3s/32 the exec permission is per segment
(256MB), not per page. The page tables have no hardware exec bit, only
the segment registers have a no-execute (N) bit. mmu_mark_initmem_nx()
sets N on all the kernel segments except the ones of the modules area.
So nothing in the vmalloc area can be executed, even when the page is
mapped with PAGE_KERNEL_ROX or PAGE_KERNEL_EXEC, because _PAGE_EXEC is
a software only bit there and the segment's N bit is what the MMU
enforces.
Before commit 1b750c2fbf82 ("powerpc: extend execmem_params for kprobes
allocations"), the kprobes insn pages came from module_alloc(). That
commit moved them to the whole of the vmalloc space, on the grounds
that kprobes use a breakpoint and don't need to be near the kernel
text. That is fine on platforms where the exec permission is per page,
as PAGE_KERNEL_ROX is then enough to make a vmalloc page executable.
It is not on book3s/32, where the modules area is not only close to
the kernel text but is also the only page-mapped area whose segment is
left executable. So the insn pages must keep coming from there.
Hence, use the modules area for EXECMEM_KPROBES on book3s/32.
Fixes: 1b750c2fbf82 ("powerpc: extend execmem_params for kprobes allocations")
Signed-off-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
---
arch/powerpc/mm/mem.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
index 77b63b52d8f2..ae1bc7359353 100644
--- a/arch/powerpc/mm/mem.c
+++ b/arch/powerpc/mm/mem.c
@@ -391,6 +391,7 @@ struct execmem_info __init *execmem_arch_setup(void)
pgprot_t kprobes_prot = strict_kernel_rwx_enabled() ? PAGE_KERNEL_ROX : PAGE_KERNEL_EXEC;
pgprot_t prot = strict_module_rwx_enabled() ? PAGE_KERNEL : PAGE_KERNEL_EXEC;
unsigned long fallback_start = 0, fallback_end = 0;
+ unsigned long kprobes_start = VMALLOC_START, kprobes_end = VMALLOC_END;
unsigned long start, end;
/*
@@ -410,6 +411,11 @@ struct execmem_info __init *execmem_arch_setup(void)
}
end = MODULES_END;
+
+ if (IS_ENABLED(CONFIG_PPC_BOOK3S_32)) {
+ kprobes_start = MODULES_VADDR;
+ kprobes_end = MODULES_END;
+ }
#else
start = VMALLOC_START;
end = VMALLOC_END;
@@ -428,8 +434,8 @@ struct execmem_info __init *execmem_arch_setup(void)
.fallback_end = fallback_end,
},
[EXECMEM_KPROBES] = {
- .start = VMALLOC_START,
- .end = VMALLOC_END,
+ .start = kprobes_start,
+ .end = kprobes_end,
.pgprot = kprobes_prot,
.alignment = 1,
},
--
2.39.5
next prev parent reply other threads:[~2026-11-13 12:32 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-13 12:31 [PATCHv2 0/3] powerpc: kprobes insn page fixes Ritesh Harjani (IBM)
2026-11-13 12:31 ` [PATCHv2 1/3] powerpc/execmem: Don't leave kprobes insn pages W+X when CONFIG_MODULES=n Ritesh Harjani (IBM)
2026-11-13 12:31 ` Ritesh Harjani (IBM) [this message]
2026-11-13 12:31 ` [PATCHv2 3/3] powerpc/ptdump: Show the exec flag of kernel mappings on e500 Ritesh Harjani (IBM)
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=82c4973addebd82923c460cb44221f5b76146afe.1794572365.git.ritesh.list@gmail.com \
--to=ritesh.list@gmail.com \
--cc=chleroy@kernel.org \
--cc=hbathini@linux.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=maddy@linux.ibm.com \
--cc=mpe@ellerman.id.au \
--cc=npiggin@gmail.com \
--cc=sshegde@linux.ibm.com \
--cc=venkat88@linux.ibm.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox