* [PATCH -next] arm64/ptrace: Fix stack-out-of-bounds read in regs_get_kernel_stack_nth()
@ 2025-06-04 0:55 Tengda Wu
2025-06-11 1:22 ` Tengda Wu
` (2 more replies)
0 siblings, 3 replies; 6+ messages in thread
From: Tengda Wu @ 2025-06-04 0:55 UTC (permalink / raw)
To: Oleg Nesterov, Catalin Marinas
Cc: Will Deacon, David A . Long, Masami Hiramatsu, linux-arm-kernel,
linux-kernel, Tengda Wu
KASAN reports a stack-out-of-bounds read in regs_get_kernel_stack_nth().
Call Trace:
[ 97.283505] BUG: KASAN: stack-out-of-bounds in regs_get_kernel_stack_nth+0xa8/0xc8
[ 97.284677] Read of size 8 at addr ffff800089277c10 by task 1.sh/2550
[ 97.285732]
[ 97.286067] CPU: 7 PID: 2550 Comm: 1.sh Not tainted 6.6.0+ #11
[ 97.287032] Hardware name: linux,dummy-virt (DT)
[ 97.287815] Call trace:
[ 97.288279] dump_backtrace+0xa0/0x128
[ 97.288946] show_stack+0x20/0x38
[ 97.289551] dump_stack_lvl+0x78/0xc8
[ 97.290203] print_address_description.constprop.0+0x84/0x3c8
[ 97.291159] print_report+0xb0/0x280
[ 97.291792] kasan_report+0x84/0xd0
[ 97.292421] __asan_load8+0x9c/0xc0
[ 97.293042] regs_get_kernel_stack_nth+0xa8/0xc8
[ 97.293835] process_fetch_insn+0x770/0xa30
[ 97.294562] kprobe_trace_func+0x254/0x3b0
[ 97.295271] kprobe_dispatcher+0x98/0xe0
[ 97.295955] kprobe_breakpoint_handler+0x1b0/0x210
[ 97.296774] call_break_hook+0xc4/0x100
[ 97.297451] brk_handler+0x24/0x78
[ 97.298073] do_debug_exception+0xac/0x178
[ 97.298785] el1_dbg+0x70/0x90
[ 97.299344] el1h_64_sync_handler+0xcc/0xe8
[ 97.300066] el1h_64_sync+0x78/0x80
[ 97.300699] kernel_clone+0x0/0x500
[ 97.301331] __arm64_sys_clone+0x70/0x90
[ 97.302084] invoke_syscall+0x68/0x198
[ 97.302746] el0_svc_common.constprop.0+0x11c/0x150
[ 97.303569] do_el0_svc+0x38/0x50
[ 97.304164] el0_svc+0x44/0x1d8
[ 97.304749] el0t_64_sync_handler+0x100/0x130
[ 97.305500] el0t_64_sync+0x188/0x190
[ 97.306151]
[ 97.306475] The buggy address belongs to stack of task 1.sh/2550
[ 97.307461] and is located at offset 0 in frame:
[ 97.308257] __se_sys_clone+0x0/0x138
[ 97.308910]
[ 97.309241] This frame has 1 object:
[ 97.309873] [48, 184) 'args'
[ 97.309876]
[ 97.310749] The buggy address belongs to the virtual mapping at
[ 97.310749] [ffff800089270000, ffff800089279000) created by:
[ 97.310749] dup_task_struct+0xc0/0x2e8
[ 97.313347]
[ 97.313674] The buggy address belongs to the physical page:
[ 97.314604] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x14f69a
[ 97.315885] flags: 0x15ffffe00000000(node=1|zone=2|lastcpupid=0xfffff)
[ 97.316957] raw: 015ffffe00000000 0000000000000000 dead000000000122 0000000000000000
[ 97.318207] raw: 0000000000000000 0000000000000000 00000001ffffffff 0000000000000000
[ 97.319445] page dumped because: kasan: bad access detected
[ 97.320371]
[ 97.320694] Memory state around the buggy address:
[ 97.321511] ffff800089277b00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 97.322681] ffff800089277b80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 97.323846] >ffff800089277c00: 00 00 f1 f1 f1 f1 f1 f1 00 00 00 00 00 00 00 00
[ 97.325023] ^
[ 97.325683] ffff800089277c80: 00 00 00 00 00 00 00 00 00 f3 f3 f3 f3 f3 f3 f3
[ 97.326856] ffff800089277d00: f3 f3 00 00 00 00 00 00 00 00 00 00 00 00 00 00
This issue seems to be related to the behavior of some gcc compilers and
was also fixed on the s390 architecture before:
commit d93a855c31b7 ("s390/ptrace: Avoid KASAN false positives in regs_get_kernel_stack_nth()")
As described in that commit, regs_get_kernel_stack_nth() has confirmed that
`addr` is on the stack, so reading the value at `*addr` should be allowed.
Use READ_ONCE_NOCHECK() helper to silence the KASAN check for this case.
Fixes: 0a8ea52c3eb1 ("arm64: Add HAVE_REGS_AND_STACK_ACCESS_API feature")
Signed-off-by: Tengda Wu <wutengda@huaweicloud.com>
---
arch/arm64/kernel/ptrace.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/kernel/ptrace.c b/arch/arm64/kernel/ptrace.c
index f79b0d5f71ac..fe3f7e554d14 100644
--- a/arch/arm64/kernel/ptrace.c
+++ b/arch/arm64/kernel/ptrace.c
@@ -141,7 +141,7 @@ unsigned long regs_get_kernel_stack_nth(struct pt_regs *regs, unsigned int n)
addr += n;
if (regs_within_kernel_stack(regs, (unsigned long)addr))
- return *addr;
+ return READ_ONCE_NOCHECK(addr);
else
return 0;
}
--
2.34.1
^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH -next] arm64/ptrace: Fix stack-out-of-bounds read in regs_get_kernel_stack_nth()
2025-06-04 0:55 [PATCH -next] arm64/ptrace: Fix stack-out-of-bounds read in regs_get_kernel_stack_nth() Tengda Wu
@ 2025-06-11 1:22 ` Tengda Wu
2025-06-12 16:33 ` Will Deacon
2025-06-12 17:27 ` Will Deacon
2 siblings, 0 replies; 6+ messages in thread
From: Tengda Wu @ 2025-06-11 1:22 UTC (permalink / raw)
To: Oleg Nesterov, Catalin Marinas
Cc: Will Deacon, David A . Long, Masami Hiramatsu, linux-arm-kernel,
linux-kernel
Ping?
Thanks,
Tengda
On 2025/6/4 8:55, Tengda Wu wrote:
> KASAN reports a stack-out-of-bounds read in regs_get_kernel_stack_nth().
>
> Call Trace:
> [ 97.283505] BUG: KASAN: stack-out-of-bounds in regs_get_kernel_stack_nth+0xa8/0xc8
> [ 97.284677] Read of size 8 at addr ffff800089277c10 by task 1.sh/2550
> [ 97.285732]
> [ 97.286067] CPU: 7 PID: 2550 Comm: 1.sh Not tainted 6.6.0+ #11
> [ 97.287032] Hardware name: linux,dummy-virt (DT)
> [ 97.287815] Call trace:
> [ 97.288279] dump_backtrace+0xa0/0x128
> [ 97.288946] show_stack+0x20/0x38
> [ 97.289551] dump_stack_lvl+0x78/0xc8
> [ 97.290203] print_address_description.constprop.0+0x84/0x3c8
> [ 97.291159] print_report+0xb0/0x280
> [ 97.291792] kasan_report+0x84/0xd0
> [ 97.292421] __asan_load8+0x9c/0xc0
> [ 97.293042] regs_get_kernel_stack_nth+0xa8/0xc8
> [ 97.293835] process_fetch_insn+0x770/0xa30
> [ 97.294562] kprobe_trace_func+0x254/0x3b0
> [ 97.295271] kprobe_dispatcher+0x98/0xe0
> [ 97.295955] kprobe_breakpoint_handler+0x1b0/0x210
> [ 97.296774] call_break_hook+0xc4/0x100
> [ 97.297451] brk_handler+0x24/0x78
> [ 97.298073] do_debug_exception+0xac/0x178
> [ 97.298785] el1_dbg+0x70/0x90
> [ 97.299344] el1h_64_sync_handler+0xcc/0xe8
> [ 97.300066] el1h_64_sync+0x78/0x80
> [ 97.300699] kernel_clone+0x0/0x500
> [ 97.301331] __arm64_sys_clone+0x70/0x90
> [ 97.302084] invoke_syscall+0x68/0x198
> [ 97.302746] el0_svc_common.constprop.0+0x11c/0x150
> [ 97.303569] do_el0_svc+0x38/0x50
> [ 97.304164] el0_svc+0x44/0x1d8
> [ 97.304749] el0t_64_sync_handler+0x100/0x130
> [ 97.305500] el0t_64_sync+0x188/0x190
> [ 97.306151]
> [ 97.306475] The buggy address belongs to stack of task 1.sh/2550
> [ 97.307461] and is located at offset 0 in frame:
> [ 97.308257] __se_sys_clone+0x0/0x138
> [ 97.308910]
> [ 97.309241] This frame has 1 object:
> [ 97.309873] [48, 184) 'args'
> [ 97.309876]
> [ 97.310749] The buggy address belongs to the virtual mapping at
> [ 97.310749] [ffff800089270000, ffff800089279000) created by:
> [ 97.310749] dup_task_struct+0xc0/0x2e8
> [ 97.313347]
> [ 97.313674] The buggy address belongs to the physical page:
> [ 97.314604] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x14f69a
> [ 97.315885] flags: 0x15ffffe00000000(node=1|zone=2|lastcpupid=0xfffff)
> [ 97.316957] raw: 015ffffe00000000 0000000000000000 dead000000000122 0000000000000000
> [ 97.318207] raw: 0000000000000000 0000000000000000 00000001ffffffff 0000000000000000
> [ 97.319445] page dumped because: kasan: bad access detected
> [ 97.320371]
> [ 97.320694] Memory state around the buggy address:
> [ 97.321511] ffff800089277b00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> [ 97.322681] ffff800089277b80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> [ 97.323846] >ffff800089277c00: 00 00 f1 f1 f1 f1 f1 f1 00 00 00 00 00 00 00 00
> [ 97.325023] ^
> [ 97.325683] ffff800089277c80: 00 00 00 00 00 00 00 00 00 f3 f3 f3 f3 f3 f3 f3
> [ 97.326856] ffff800089277d00: f3 f3 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>
> This issue seems to be related to the behavior of some gcc compilers and
> was also fixed on the s390 architecture before:
>
> commit d93a855c31b7 ("s390/ptrace: Avoid KASAN false positives in regs_get_kernel_stack_nth()")
>
> As described in that commit, regs_get_kernel_stack_nth() has confirmed that
> `addr` is on the stack, so reading the value at `*addr` should be allowed.
> Use READ_ONCE_NOCHECK() helper to silence the KASAN check for this case.
>
> Fixes: 0a8ea52c3eb1 ("arm64: Add HAVE_REGS_AND_STACK_ACCESS_API feature")
> Signed-off-by: Tengda Wu <wutengda@huaweicloud.com>
> ---
> arch/arm64/kernel/ptrace.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm64/kernel/ptrace.c b/arch/arm64/kernel/ptrace.c
> index f79b0d5f71ac..fe3f7e554d14 100644
> --- a/arch/arm64/kernel/ptrace.c
> +++ b/arch/arm64/kernel/ptrace.c
> @@ -141,7 +141,7 @@ unsigned long regs_get_kernel_stack_nth(struct pt_regs *regs, unsigned int n)
>
> addr += n;
> if (regs_within_kernel_stack(regs, (unsigned long)addr))
> - return *addr;
> + return READ_ONCE_NOCHECK(addr);
> else
> return 0;
> }
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH -next] arm64/ptrace: Fix stack-out-of-bounds read in regs_get_kernel_stack_nth()
2025-06-04 0:55 [PATCH -next] arm64/ptrace: Fix stack-out-of-bounds read in regs_get_kernel_stack_nth() Tengda Wu
2025-06-11 1:22 ` Tengda Wu
@ 2025-06-12 16:33 ` Will Deacon
2025-06-13 15:04 ` Heiko Carstens
2025-06-16 7:57 ` Tengda Wu
2025-06-12 17:27 ` Will Deacon
2 siblings, 2 replies; 6+ messages in thread
From: Will Deacon @ 2025-06-12 16:33 UTC (permalink / raw)
To: Tengda Wu
Cc: Oleg Nesterov, Catalin Marinas, David A . Long, Masami Hiramatsu,
linux-arm-kernel, linux-kernel
On Wed, Jun 04, 2025 at 12:55:33AM +0000, Tengda Wu wrote:
> diff --git a/arch/arm64/kernel/ptrace.c b/arch/arm64/kernel/ptrace.c
> index f79b0d5f71ac..fe3f7e554d14 100644
> --- a/arch/arm64/kernel/ptrace.c
> +++ b/arch/arm64/kernel/ptrace.c
> @@ -141,7 +141,7 @@ unsigned long regs_get_kernel_stack_nth(struct pt_regs *regs, unsigned int n)
>
> addr += n;
> if (regs_within_kernel_stack(regs, (unsigned long)addr))
> - return *addr;
> + return READ_ONCE_NOCHECK(addr);
I think this should be '*addr', but that makes me wonder wtf s390 is
doing...
Will
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH -next] arm64/ptrace: Fix stack-out-of-bounds read in regs_get_kernel_stack_nth()
2025-06-04 0:55 [PATCH -next] arm64/ptrace: Fix stack-out-of-bounds read in regs_get_kernel_stack_nth() Tengda Wu
2025-06-11 1:22 ` Tengda Wu
2025-06-12 16:33 ` Will Deacon
@ 2025-06-12 17:27 ` Will Deacon
2 siblings, 0 replies; 6+ messages in thread
From: Will Deacon @ 2025-06-12 17:27 UTC (permalink / raw)
To: Oleg Nesterov, Catalin Marinas, Tengda Wu
Cc: kernel-team, Will Deacon, David A . Long, Masami Hiramatsu,
linux-arm-kernel, linux-kernel
On Wed, 04 Jun 2025 00:55:33 +0000, Tengda Wu wrote:
> KASAN reports a stack-out-of-bounds read in regs_get_kernel_stack_nth().
>
> Call Trace:
> [ 97.283505] BUG: KASAN: stack-out-of-bounds in regs_get_kernel_stack_nth+0xa8/0xc8
> [ 97.284677] Read of size 8 at addr ffff800089277c10 by task 1.sh/2550
> [ 97.285732]
> [ 97.286067] CPU: 7 PID: 2550 Comm: 1.sh Not tainted 6.6.0+ #11
> [ 97.287032] Hardware name: linux,dummy-virt (DT)
> [ 97.287815] Call trace:
> [ 97.288279] dump_backtrace+0xa0/0x128
> [ 97.288946] show_stack+0x20/0x38
> [ 97.289551] dump_stack_lvl+0x78/0xc8
> [ 97.290203] print_address_description.constprop.0+0x84/0x3c8
> [ 97.291159] print_report+0xb0/0x280
> [ 97.291792] kasan_report+0x84/0xd0
> [ 97.292421] __asan_load8+0x9c/0xc0
> [ 97.293042] regs_get_kernel_stack_nth+0xa8/0xc8
> [ 97.293835] process_fetch_insn+0x770/0xa30
> [ 97.294562] kprobe_trace_func+0x254/0x3b0
> [ 97.295271] kprobe_dispatcher+0x98/0xe0
> [ 97.295955] kprobe_breakpoint_handler+0x1b0/0x210
> [ 97.296774] call_break_hook+0xc4/0x100
> [ 97.297451] brk_handler+0x24/0x78
> [ 97.298073] do_debug_exception+0xac/0x178
> [ 97.298785] el1_dbg+0x70/0x90
> [ 97.299344] el1h_64_sync_handler+0xcc/0xe8
> [ 97.300066] el1h_64_sync+0x78/0x80
> [ 97.300699] kernel_clone+0x0/0x500
> [ 97.301331] __arm64_sys_clone+0x70/0x90
> [ 97.302084] invoke_syscall+0x68/0x198
> [ 97.302746] el0_svc_common.constprop.0+0x11c/0x150
> [ 97.303569] do_el0_svc+0x38/0x50
> [ 97.304164] el0_svc+0x44/0x1d8
> [ 97.304749] el0t_64_sync_handler+0x100/0x130
> [ 97.305500] el0t_64_sync+0x188/0x190
> [ 97.306151]
> [ 97.306475] The buggy address belongs to stack of task 1.sh/2550
> [ 97.307461] and is located at offset 0 in frame:
> [ 97.308257] __se_sys_clone+0x0/0x138
> [ 97.308910]
> [ 97.309241] This frame has 1 object:
> [ 97.309873] [48, 184) 'args'
> [ 97.309876]
> [ 97.310749] The buggy address belongs to the virtual mapping at
> [ 97.310749] [ffff800089270000, ffff800089279000) created by:
> [ 97.310749] dup_task_struct+0xc0/0x2e8
> [ 97.313347]
> [ 97.313674] The buggy address belongs to the physical page:
> [ 97.314604] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x14f69a
> [ 97.315885] flags: 0x15ffffe00000000(node=1|zone=2|lastcpupid=0xfffff)
> [ 97.316957] raw: 015ffffe00000000 0000000000000000 dead000000000122 0000000000000000
> [ 97.318207] raw: 0000000000000000 0000000000000000 00000001ffffffff 0000000000000000
> [ 97.319445] page dumped because: kasan: bad access detected
> [ 97.320371]
> [ 97.320694] Memory state around the buggy address:
> [ 97.321511] ffff800089277b00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> [ 97.322681] ffff800089277b80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> [ 97.323846] >ffff800089277c00: 00 00 f1 f1 f1 f1 f1 f1 00 00 00 00 00 00 00 00
> [ 97.325023] ^
> [ 97.325683] ffff800089277c80: 00 00 00 00 00 00 00 00 00 f3 f3 f3 f3 f3 f3 f3
> [ 97.326856] ffff800089277d00: f3 f3 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>
> [...]
Applied (using *addr) to arm64 (for-next/fixes), thanks!
[1/1] arm64/ptrace: Fix stack-out-of-bounds read in regs_get_kernel_stack_nth()
https://git.kernel.org/arm64/c/39dfc971e42d
Cheers,
--
Will
https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH -next] arm64/ptrace: Fix stack-out-of-bounds read in regs_get_kernel_stack_nth()
2025-06-12 16:33 ` Will Deacon
@ 2025-06-13 15:04 ` Heiko Carstens
2025-06-16 7:57 ` Tengda Wu
1 sibling, 0 replies; 6+ messages in thread
From: Heiko Carstens @ 2025-06-13 15:04 UTC (permalink / raw)
To: Will Deacon
Cc: Tengda Wu, Oleg Nesterov, Catalin Marinas, David A . Long,
Masami Hiramatsu, linux-arm-kernel, linux-kernel
On Thu, Jun 12, 2025 at 05:33:32PM +0100, Will Deacon wrote:
> On Wed, Jun 04, 2025 at 12:55:33AM +0000, Tengda Wu wrote:
> > diff --git a/arch/arm64/kernel/ptrace.c b/arch/arm64/kernel/ptrace.c
> > index f79b0d5f71ac..fe3f7e554d14 100644
> > --- a/arch/arm64/kernel/ptrace.c
> > +++ b/arch/arm64/kernel/ptrace.c
> > @@ -141,7 +141,7 @@ unsigned long regs_get_kernel_stack_nth(struct pt_regs *regs, unsigned int n)
> >
> > addr += n;
> > if (regs_within_kernel_stack(regs, (unsigned long)addr))
> > - return *addr;
> > + return READ_ONCE_NOCHECK(addr);
>
> I think this should be '*addr', but that makes me wonder wtf s390 is
> doing...
That's obviously a brown paper bag bug in our code... will be fixed.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH -next] arm64/ptrace: Fix stack-out-of-bounds read in regs_get_kernel_stack_nth()
2025-06-12 16:33 ` Will Deacon
2025-06-13 15:04 ` Heiko Carstens
@ 2025-06-16 7:57 ` Tengda Wu
1 sibling, 0 replies; 6+ messages in thread
From: Tengda Wu @ 2025-06-16 7:57 UTC (permalink / raw)
To: Will Deacon
Cc: Oleg Nesterov, Catalin Marinas, David A . Long, Masami Hiramatsu,
linux-arm-kernel, linux-kernel
On 2025/6/13 0:33, Will Deacon wrote:
> On Wed, Jun 04, 2025 at 12:55:33AM +0000, Tengda Wu wrote:
>> diff --git a/arch/arm64/kernel/ptrace.c b/arch/arm64/kernel/ptrace.c
>> index f79b0d5f71ac..fe3f7e554d14 100644
>> --- a/arch/arm64/kernel/ptrace.c
>> +++ b/arch/arm64/kernel/ptrace.c
>> @@ -141,7 +141,7 @@ unsigned long regs_get_kernel_stack_nth(struct pt_regs *regs, unsigned int n)
>>
>> addr += n;
>> if (regs_within_kernel_stack(regs, (unsigned long)addr))
>> - return *addr;
>> + return READ_ONCE_NOCHECK(addr);
>
> I think this should be '*addr', but that makes me wonder wtf s390 is
> doing...
>
> Will
Sorry, I just received this email as there have been some issues
with my mailbox recently. I was about to send the v2 version with
the '*' mark, but I found out you have already fixed and applied
it to the linux-next. Thank you for your tolerance.
Tengda
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2025-06-16 7:57 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-06-04 0:55 [PATCH -next] arm64/ptrace: Fix stack-out-of-bounds read in regs_get_kernel_stack_nth() Tengda Wu
2025-06-11 1:22 ` Tengda Wu
2025-06-12 16:33 ` Will Deacon
2025-06-13 15:04 ` Heiko Carstens
2025-06-16 7:57 ` Tengda Wu
2025-06-12 17:27 ` Will Deacon
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).