* Re: [PATCH 1/1] arm64: Print slab alloc and free paths for addresses in registers
2025-11-27 6:02 ` [PATCH 1/1] arm64: Print slab alloc and free paths for addresses in registers Onkarnath
@ 2025-11-27 9:15 ` Mark Rutland
0 siblings, 0 replies; 2+ messages in thread
From: Mark Rutland @ 2025-11-27 9:15 UTC (permalink / raw)
To: Onkarnath
Cc: catalin.marinas, will, ada.coupriediaz, thuth, broonie, song,
yeoreum.yun, kevin.brodsky, ryan.roberts, jeremy.linton, maz,
smostafa, leitao, bigeasy, kees, linux-arm-kernel, linux-kernel,
maninder1.s, r.thapliyal, Sarvesh Kadam
On Thu, Nov 27, 2025 at 11:32:27AM +0530, Onkarnath wrote:
> When debugging use-after-free kernel oopses, knowing the allocation and
> freeing paths of an object is crucial. Like arm this patch enhances arm64
> debugging by checking if register addresses belong to a slab and printing
> their corresponding alloc and free paths.
>
> For example x21 prints alloc and free path:
>
> pc : crash_init+0x44/0x64 [crash]
> lr : crash_init+0x34/0x64 [crash]
> .....
These dots are hiding *tonnes* of lines.
Please see my response from the last time this was proposed:
https://lore.kernel.org/linux-arm-kernel/ZcDa2RXC6z7XuwAD@FVFF77S0Q05N/
At a high level, I still don't think this is a good idea.
> Register x21 information: slab task_struct start ffff0000c3cc7000 data offset 64 pointer offset 0 size 3904 allocated at copy_process+0x1ac/0x14a4
> kmem_cache_alloc_node_noprof+0x208/0x4a8
> copy_process+0x1ac/0x14a4
> kernel_clone+0x70/0x380
> __arm64_sys_fork+0x40/0x7c
> invoke_syscall+0x48/0x104
> el0_svc_common.constprop.0+0x40/0xe0
> do_el0_svc_compat+0x1c/0x34
> el0_svc_compat+0x2c/0x90
> el0t_32_sync_handler+0x88/0xac
> el0t_32_sync+0x19c/0x1a0
> Free path:
> kmem_cache_free+0x3c0/0x430
> free_task+0x54/0x80
> __put_task_struct+0x100/0x15c
> __put_task_struct_rcu_cb+0x14/0x20
> rcu_core+0x264/0x680
> rcu_core_si+0x10/0x1c
> handle_softirqs+0x100/0x244
> __do_softirq+0x14/0x20
>
> Co-developed-by: Sarvesh Kadam <s.kadam@samsung.com>
> Signed-off-by: Sarvesh Kadam <s.kadam@samsung.com>
> Signed-off-by: Onkarnath <onkarnath.1@samsung.com>
> ---
> arch/arm64/include/asm/system_misc.h | 1 +
> arch/arm64/kernel/process.c | 11 +++++++++++
> arch/arm64/kernel/traps.c | 2 +-
> 3 files changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/include/asm/system_misc.h b/arch/arm64/include/asm/system_misc.h
> index d316a804eb38..9cb9749d8853 100644
> --- a/arch/arm64/include/asm/system_misc.h
> +++ b/arch/arm64/include/asm/system_misc.h
> @@ -27,6 +27,7 @@ void arm64_notify_die(const char *str, struct pt_regs *regs,
>
> struct mm_struct;
> extern void __show_regs(struct pt_regs *);
> +extern void __show_regs_alloc_free(struct pt_regs *regs);
>
> #endif /* __ASSEMBLER__ */
>
> diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
> index fba7ca102a8c..7738ec8e5cd5 100644
> --- a/arch/arm64/kernel/process.c
> +++ b/arch/arm64/kernel/process.c
> @@ -199,6 +199,17 @@ static void print_pstate(struct pt_regs *regs)
> }
> }
>
> +void __show_regs_alloc_free(struct pt_regs *regs)
> +{
> + int i;
> +
> + /* check for x0 - x31 only */
> + for (i = 0; i < 31; i++) {
> + pr_alert("Register x%d information:", i);
> + mem_dump_obj((void *)regs->regs[i]);
> + }
> +}
The comment should say 'x31' rather than 'x30'.
> +
> void __show_regs(struct pt_regs *regs)
> {
> int i, top_reg;
> diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c
> index 914282016069..3b01379b8880 100644
> --- a/arch/arm64/kernel/traps.c
> +++ b/arch/arm64/kernel/traps.c
> @@ -189,7 +189,7 @@ static int __die(const char *str, long err, struct pt_regs *regs)
>
> print_modules();
> show_regs(regs);
> -
> + __show_regs_alloc_free(regs);
> if (user_mode(regs))
> return ret;
If the regs are user regs, then the registers do not contain kernel
addresses. We shouldn't interpret the registers in that case.
We use die() and __die() for many exceptions that are entirely unrelated
to use-after-free (e.g. BTI exceptions), so this is going to be noisy
for no benefit.
Mark.
^ permalink raw reply [flat|nested] 2+ messages in thread