[PATCH 1/1] arm: get task_stack reference before dump_backtrace

[PATCH 1/1] arm: get task_stack reference before dump_backtrace

[Maninder Singh]

With Support of THREAD_INFO_IN_TASK, stack of task can be
freed earlier than task (even if task's reference is taken),
and it needs separate reference with try_get_task_stack()
before using the stack.
Otherwise if someone calls show_stack() for task, it can oops
the kernel like below: (Tried with normal race of show_stack when
task still exists, but its stack is freed)

8<--- cut here ---
Unable to handle kernel paging request at virtual address f8aebec4 when read
[f8aebec4] *pgd=83c2c811, *pte=00000000, *ppte=00000000
Internal error: Oops: 7 [#1] SMP ARM
..
CPU: 0 UID: 0 PID: 70 Comm: cat Not tainted 7.0.0-rc2-next-20260302+ #26 VOLUNTARY
..
PC is at __read_once_word_nocheck+0x0/0x8
LR is at unwind_frame+0x6b0/0xa90
...
Call trace:
 __read_once_word_nocheck from unwind_frame+0x6b0/0xa90
 unwind_frame from unwind_backtrace+0x178/0x1e0
 unwind_backtrace from show_stack+0x10/0x14
...

ARM64 also takes care of it in dump_backtrace(), so same logic
is added for ARM also.

Fixes: 18ed1c01a7dd ("ARM: smp: Enable THREAD_INFO_IN_TASK")
Signed-off-by: Maninder Singh <maninder1.s@samsung.com>
---
 arch/arm/kernel/traps.c  |  9 +++++++--
 arch/arm/kernel/unwind.c | 10 ++++++++--
 2 files changed, 15 insertions(+), 4 deletions(-)

diff --git a/arch/arm/kernel/traps.c b/arch/arm/kernel/traps.c
index afbd2ebe5c39..770dcb1dc683 100644
--- a/arch/arm/kernel/traps.c
+++ b/arch/arm/kernel/traps.c
@@ -221,11 +221,14 @@ void dump_backtrace(struct pt_regs *regs, struct task_struct *tsk,
 	unsigned int fp, mode;
 	int ok = 1;
 
-	printk("%sCall trace: ", loglvl);
-
 	if (!tsk)
 		tsk = current;
 
+	if (!try_get_task_stack(tsk))
+		return;
+
+	printk("%sCall trace: ", loglvl);
+
 	if (regs) {
 		fp = frame_pointer(regs);
 		mode = processor_mode(regs);
@@ -249,6 +252,8 @@ void dump_backtrace(struct pt_regs *regs, struct task_struct *tsk,
 
 	if (ok)
 		c_backtrace(fp, mode, loglvl);
+
+	put_task_stack(tsk);
 }
 #endif
 
diff --git a/arch/arm/kernel/unwind.c b/arch/arm/kernel/unwind.c
index c91cb0e1585e..990692714288 100644
--- a/arch/arm/kernel/unwind.c
+++ b/arch/arm/kernel/unwind.c
@@ -29,6 +29,7 @@
 #include <linux/spinlock.h>
 #include <linux/list.h>
 #include <linux/module.h>
+#include <linux/sched/task_stack.h>
 
 #include <asm/stacktrace.h>
 #include <asm/traps.h>
@@ -524,13 +525,16 @@ void unwind_backtrace(struct pt_regs *regs, struct task_struct *tsk,
 {
 	struct stackframe frame;
 
-	printk("%sCall trace: ", loglvl);
-
 	pr_debug("%s(regs = %p tsk = %p)\n", __func__, regs, tsk);
 
 	if (!tsk)
 		tsk = current;
 
+	if (!try_get_task_stack(tsk))
+		return;
+
+	printk("%sCall trace: ", loglvl);
+
 	if (regs) {
 		arm_get_current_stackframe(regs, &frame);
 		/* PC might be corrupted, use LR in that case. */
@@ -567,6 +571,8 @@ void unwind_backtrace(struct pt_regs *regs, struct task_struct *tsk,
 			break;
 		dump_backtrace_entry(where, frame.pc, frame.sp - 4, loglvl);
 	}
+
+	put_task_stack(tsk);
 }
 
 struct unwind_table *unwind_table_add(unsigned long start, unsigned long size,
-- 
2.34.1

Re: [PATCH 1/1] arm: get task_stack reference before dump_backtrace

[Linus Walleij]

On Thu, Mar 5, 2026 at 8:05 AM Maninder Singh <maninder1.s@samsung.com> wrote:

> With Support of THREAD_INFO_IN_TASK, stack of task can be
> freed earlier than task (even if task's reference is taken),
> and it needs separate reference with try_get_task_stack()
> before using the stack.
> Otherwise if someone calls show_stack() for task, it can oops
> the kernel like below: (Tried with normal race of show_stack when
> task still exists, but its stack is freed)
>
> 8<--- cut here ---
> Unable to handle kernel paging request at virtual address f8aebec4 when read
> [f8aebec4] *pgd=83c2c811, *pte=00000000, *ppte=00000000
> Internal error: Oops: 7 [#1] SMP ARM
> ..
> CPU: 0 UID: 0 PID: 70 Comm: cat Not tainted 7.0.0-rc2-next-20260302+ #26 VOLUNTARY
> ..
> PC is at __read_once_word_nocheck+0x0/0x8
> LR is at unwind_frame+0x6b0/0xa90
> ...
> Call trace:
>  __read_once_word_nocheck from unwind_frame+0x6b0/0xa90
>  unwind_frame from unwind_backtrace+0x178/0x1e0
>  unwind_backtrace from show_stack+0x10/0x14
> ...
>
> ARM64 also takes care of it in dump_backtrace(), so same logic
> is added for ARM also.
>
> Fixes: 18ed1c01a7dd ("ARM: smp: Enable THREAD_INFO_IN_TASK")
> Signed-off-by: Maninder Singh <maninder1.s@samsung.com>

Ard B should review this but it looks right to me:
Acked-by: Linus Walleij <linusw@kernel.org>

Yours,
Linus Walleij

Re: [PATCH 1/1] arm: get task_stack reference before dump_backtrace

[Russell King (Oracle)]

On Thu, Mar 05, 2026 at 12:35:27PM +0530, Maninder Singh wrote:
> With Support of THREAD_INFO_IN_TASK, stack of task can be
> freed earlier than task (even if task's reference is taken),
> and it needs separate reference with try_get_task_stack()
> before using the stack.
> Otherwise if someone calls show_stack() for task, it can oops
> the kernel like below: (Tried with normal race of show_stack when
> task still exists, but its stack is freed)

Looking at x86, it also has THREAD_INFO_IN_TASK, but I see nothing like
this in show_stack(). How come x86 isn't similarly buggy?

> 
> 8<--- cut here ---
> Unable to handle kernel paging request at virtual address f8aebec4 when read
> [f8aebec4] *pgd=83c2c811, *pte=00000000, *ppte=00000000
> Internal error: Oops: 7 [#1] SMP ARM
> ..
> CPU: 0 UID: 0 PID: 70 Comm: cat Not tainted 7.0.0-rc2-next-20260302+ #26 VOLUNTARY
> ..
> PC is at __read_once_word_nocheck+0x0/0x8
> LR is at unwind_frame+0x6b0/0xa90
> ...
> Call trace:
>  __read_once_word_nocheck from unwind_frame+0x6b0/0xa90
>  unwind_frame from unwind_backtrace+0x178/0x1e0
>  unwind_backtrace from show_stack+0x10/0x14
> ...

"otherwise if someone calls show_stack() for task" ... and the stack
trace given stops at show_stack() and doesn't show the "someone".

I'd like to know _how_ this happens, and why ARM64 and now 32-bit ARM
are different from x86.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!

RE: [PATCH 1/1] arm: get task_stack reference before dump_backtrace

[Maninder Singh]

Hi,

>> With Support of THREAD_INFO_IN_TASK, stack of task can be
>> freed earlier than task (even if task's reference is taken),
>> and it needs separate reference with try_get_task_stack()
>> before using the stack.
>> Otherwise if someone calls show_stack() for task, it can oops
>> the kernel like below: (Tried with normal race of show_stack when
>> task still exists, but its stack is freed)
>
> Looking at x86, it also has THREAD_INFO_IN_TASK, but I see nothing like
> this in show_stack(). How come x86 isn't similarly buggy?

I think x86 also has same issue, some of other architectures which supports
THREAD_INFO_IN_TASK has added try_get_task_stack() in show_stack(), but not *all*

   8   2293  arch/powerpc/kernel/process.c <<show_stack>>
             if (!try_get_task_stack(tsk))

   4    488  arch/arm64/kernel/stacktrace.c <<dump_backtrace>>
             if (!try_get_task_stack(tsk))


>> 
>> ...
>
>"otherwise if someone calls show_stack() for task" ... and the stack
>trace given stops at show_stack() and doesn't show the "someone".
>
>I'd like to know _how_ this happens, and why ARM64 and now 32-bit ARM
>are different from x86.

I tried to simulate same thing on x86_64, it is also crashing.

Just a dummy code to save task_struct to reproduce the race:

+       rcu_read_lock();
+       for_each_process(p) {
+               if (!strcmp(p->comm, "sleep")) {
+                       check_task = p;
+                       get_task_struct(p);
+                       pr_emerg("get done for %s %d\n", p->comm, p->pid);
+               }
+       }
+       rcu_read_unlock();

// in mean time here sleep binary will be exited.

+       show_stack(check_task,  NULL, KERN_EMERG);

//OOPs

/ # cat /proc/meminfo
[   49.885891] Call Trace:
[   49.887151] BUG: unable to handle page fault for address: ffffb57400213de8
[   49.887563] #PF: supervisor read access in kernel mode
[   49.887737] #PF: error_code(0x0000) - not-present page
[   49.887999] PGD 1000067 P4D 1000067 PUD 113b067 PMD 1bcb067 PTE 0
[   49.888588] Oops: Oops: 0000 [#1] SMP NOPTI
[   49.889329] CPU: 0 UID: 0 PID: 68 Comm: cat Not tainted 7.0.0-rc2-next-20260302-00003-gb7e059f3a5ae-dirty #49 PREEMPT(lazy)
[   49.889789] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
[   49.890204] RIP: 0010:__unwind_start+0x118/0x1c0
[   49.890471] Code: 75 28 48 8d b8 ff 0f 00 00 48 81 e7 00 f0 ff ff e8 ed ce fb ff 85 c0 75 ae eb 9c 48 8b 86 08 0c 00 00 48 8d 78 38 48 89 7d 48 <48> 8b 50 28 48 89 55 50 48 8b 4c
[   49.891163] RSP: 0018:ffffb57400207b00 EFLAGS: 00000246
[   49.891385] RAX: ffffb57400213dc0 RBX: ffffb57400213dc0 RCX: 0000000000000000
[   49.891615] RDX: 0000000000000000 RSI: ffff99ec41b6cc40 RDI: ffffb57400213df8
[   49.891867] RBP: ffffb57400207b68 R08: ffffffffae53e908 R09: 00000000ffffdfff
[   49.892101] R10: ffffffffae45e920 R11: ffffffffae50e920 R12: 0000000000000000
[   49.892332] R13: ffff99ec41b6f298 R14: ffffb57400207b68 R15: ffffffffae24615e
[   49.892670] FS:  00000000081ed3c0(0000) GS:ffff99ec9887b000(0000) knlGS:0000000000000000
[   49.892950] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[   49.893147] CR2: ffffb57400213de8 CR3: 0000000001d2d000 CR4: 00000000000006f0
[   49.893485] Call Trace:
[   49.893700]  <TASK>
[   49.893810]  __show_trace_log_lvl+0x31f/0x360
[   49.893988]  ? mas_store_prealloc+0x99/0x2c0
[   49.894169]  meminfo_proc_show+0xdd/0x9a0
[   49.894312]  ? seq_open+0x3b/0x60
[   49.894435]  ? __pfx_meminfo_proc_show+0x10/0x10
[   49.894568]  ? file_ra_state_init+0x10/0x30
[   49.894731]  ? __pte_offset_map+0x16/0xd0
[   49.894871]  ? seq_read_iter+0x38e/0x4b0
[   49.895004]  seq_read_iter+0x109/0x4b0
[   49.895125]  copy_splice_read+0x18f/0x330
[   49.895272]  splice_direct_to_actor+0xb4/0x250
[   49.895420]  ? __pfx_direct_splice_actor+0x10/0x10
[   49.895582]  do_splice_direct+0x71/0xb0
[   49.895730]  ? __pfx_direct_file_splice_eof+0x10/0x10
[   49.895908]  do_sendfile+0x361/0x420
[   49.896049]  do_syscall_64+0xf1/0x520
[   49.896197]  entry_SYSCALL_64_after_hwframe+0x77/0x7f
[   49.896375] RIP: 0033:0x4a8d3e
[   49.896634] Code: c3 0f 1f 00 4c 89 d2 4c 89 c6 e9 fd fd ff ff 0f 1f 44 00 00 31 c0 c3 0f 1f 44 00 00 f3 0f 1e fa 49 89 ca b8 28 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c8
[   49.897221] RSP: 002b:00007ffe75342478 EFLAGS: 00000246 ORIG_RAX: 0000000000000028
[   49.897486] RAX: ffffffffffffffda RBX: 0000000001000000 RCX: 00000000004a8d3e
[   49.897747] RDX: 0000000000000000 RSI: 0000000000000003 RDI: 0000000000000001
[   49.897977] RBP: 0000000000000003 R08: 0000000000000001 R09: 0000000000000000
[   49.898221] R10: 0000000001000000 R11: 0000000000000246 R12: 0000000000000003
[   49.898489] R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000000001
[   49.898764]  </TASK>
[   49.898898] Modules linked in:
[   49.899259] CR2: ffffb57400213de8
[   49.899762] ---[ end trace 0000000000000000 ]---
[   49.900187] RIP: 0010:__unwind_start+0x118/0x1c0
[   49.900391] Code: 75 28 48 8d b8 ff 0f 00 00 48 81 e7 00 f0 ff ff e8 ed ce fb ff 85 c0 75 ae eb 9c 48 8b 86 08 0c 00 00 48 8d 78 38 48 89 7d 48 <48> 8b 50 28 48 89 55 50 48 8b 4c
[   49.901001] RSP: 0018:ffffb57400207b00 EFLAGS: 00000246
[   49.901188] RAX: ffffb57400213dc0 RBX: ffffb57400213dc0 RCX: 0000000000000000
[   49.901431] RDX: 0000000000000000 RSI: ffff99ec41b6cc40 RDI: ffffb57400213df8
[   49.901680] RBP: ffffb57400207b68 R08: ffffffffae53e908 R09: 00000000ffffdfff
[   49.901918] R10: ffffffffae45e920 R11: ffffffffae50e920 R12: 0000000000000000
[   49.902182] R13: ffff99ec41b6f298 R14: ffffb57400207b68 R15: ffffffffae24615e
[   49.902417] FS:  00000000081ed3c0(0000) GS:ffff99ec9887b000(0000) knlGS:0000000000000000
[   49.902694] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[   49.902896] CR2: ffffb57400213de8 CR3: 0000000001d2d000 CR4: 00000000000006f0


So It has to be same way for all archs, as mentioned in Help of THREAD_INFO_IN_TASK

config THREAD_INFO_IN_TASK
        bool
        help
          Select this to move thread_info off the stack into task_struct.  To
          make this work, an arch will need to remove all thread_info fields
          except flags and fix any runtime bugs.

          One subtle change that will be needed is to use try_get_task_stack()
          and put_task_stack() in save_thread_stack_tsk() and save_thread_stack_tsk().

alongwith save_thread_stack_tsk and save_thread_stack_tsk, same thing shall be done for show_stack also.

Thanks & Regards,
Maninder Singh

Re: RE: [PATCH 1/1] arm: get task_stack reference before dump_backtrace

[bigeasy]

On 2026-03-09 11:23:28 [+0530], Maninder Singh wrote:
> Hi,
Hi,

> >"otherwise if someone calls show_stack() for task" ... and the stack
> >trace given stops at show_stack() and doesn't show the "someone".
> >
> >I'd like to know _how_ this happens, and why ARM64 and now 32-bit ARM
> >are different from x86.
> 
> I tried to simulate same thing on x86_64, it is also crashing.
> 
> Just a dummy code to save task_struct to reproduce the race:
> 
> +       rcu_read_lock();
> +       for_each_process(p) {
> +               if (!strcmp(p->comm, "sleep")) {
> +                       check_task = p;
> +                       get_task_struct(p);
> +                       pr_emerg("get done for %s %d\n", p->comm, p->pid);
> +               }
> +       }
> +       rcu_read_unlock();
> 
> // in mean time here sleep binary will be exited.
> 
> +       show_stack(check_task,  NULL, KERN_EMERG);

The task's stack is released on its final schedule() invocation.
Therefore holding task_struct does not hold the stack of the task if it
is separated out of task_struct and can be gone if the tasks quits.

Therefore holding a reference to the stack while accessing it, like
during a backtrace, makes sense and is required if the task is not
current.

Let me add this to my list and tackle it later today for x86. Then we
get probably Russell on board for ARM.

> //OOPs

Sebastian

RE:(3) [PATCH 1/1] arm: get task_stack reference before dump_backtrace

[Maninder Singh]

Hi,

> Hi,
> 
> > >"otherwise if someone calls show_stack() for task" ... and the stack
> > >trace given stops at show_stack() and doesn't show the "someone".
> > >
> > >I'd like to know _how_ this happens, and why ARM64 and now 32-bit ARM
> > >are different from x86.
> > 
> > I tried to simulate same thing on x86_64, it is also crashing.
> > 
> > Just a dummy code to save task_struct to reproduce the race:
> > 
> > +       rcu_read_lock();
> > +       for_each_process(p) {
> > +               if (!strcmp(p->comm, "sleep")) {
> > +                       check_task = p;
> > +                       get_task_struct(p);
> > +                       pr_emerg("get done for %s %d\n", p->comm, p->pid);
> > +               }
> > +       }
> > +       rcu_read_unlock();
> > 
> > // in mean time here sleep binary will be exited.
> > 
> > +       show_stack(check_task,  NULL, KERN_EMERG);
> 
> The task's stack is released on its final schedule() invocation.
> Therefore holding task_struct does not hold the stack of the task if it
> is separated out of task_struct and can be gone if the tasks quits.
> 
> Therefore holding a reference to the stack while accessing it, like
> during a backtrace, makes sense and is required if the task is not
> current.
> 
> Let me add this to my list and tackle it later today for x86. Then we
> get probably Russell on board for ARM.
> 

Thanks :)

I have checked more details about missing this handling from x86 and found the reason.
Originally show_stack() was calling show_stack_log_lvl()
which had proper call to try_get_task_stack().

It was replaced with show_trace_log_lvl() later. Which removed this check.

Below commit did that.

commit 0ee1dd9f5e7eae4e55f95935b72d4beecb03de9c (HEAD)
Author: Josh Poimboeuf <jpoimboe@redhat.com>
Date:   Tue Oct 25 09:51:13 2016 -0500

    x86/dumpstack: Remove raw stack dump
...
...


-void show_stack_log_lvl(struct task_struct *task, struct pt_regs *regs,
-                       unsigned long *sp, char *log_lvl)
-{
...
...
-       if (!try_get_task_stack(task))
-               return;
-
...

@@ -171,12 +170,12 @@ void show_stack(struct task_struct *task, unsigned long *sp)
        if (!sp && task == current)
                sp = get_stack_pointer(current, NULL);

-       show_stack_log_lvl(task, NULL, sp, KERN_DEFAULT);
+       show_trace_log_lvl(task, NULL, sp, KERN_DEFAULT);
 }



So I think x86 patch shall also be merged to kernel:
https://lkml.org/lkml/2026/3/11/317


Thanks and regrads
Maninder singh

RE: [PATCH 1/1] arm: get task_stack reference before dump_backtrace

[Maninder Singh]

Hi,

> On Thu, Mar 05, 2026 at 12:35:27PM +0530, Maninder Singh wrote:
>> With Support of THREAD_INFO_IN_TASK, stack of task can be
>> freed earlier than task (even if task's reference is taken),
>> and it needs separate reference with try_get_task_stack()
>> before using the stack.
>> Otherwise if someone calls show_stack() for task, it can oops
>> the kernel like below: (Tried with normal race of show_stack when
>> task still exists, but its stack is freed)
> 
> Looking at x86, it also has THREAD_INFO_IN_TASK, but I see nothing like
> this in show_stack(). How come x86 isn't similarly buggy?
> 

Thanks for your inputs.

I sent patch for x86 also to report same issue, but no replies :)

https://lkml.org/lkml/2026/3/11/317

So I guess we will never know if it is buggy or not.
and why ARM64 has done the checkings and there is no need for x86 and ARM.

 
>> 8<--- cut here ---
>> Unable to handle kernel paging request at virtual address f8aebec4 when read
>> [f8aebec4] *pgd=83c2c811, *pte=00000000, *ppte=00000000
>> Internal error: Oops: 7 [#1] SMP ARM
>> ..
>> CPU: 0 UID: 0 PID: 70 Comm: cat Not tainted 7.0.0-rc2-next-20260302+ #26 VOLUNTARY
>> ..
>> PC is at __read_once_word_nocheck+0x0/0x8
>> LR is at unwind_frame+0x6b0/0xa90
>> ...
>> Call trace:
>>  __read_once_word_nocheck from unwind_frame+0x6b0/0xa90
>>  unwind_frame from unwind_backtrace+0x178/0x1e0
>>  unwind_backtrace from show_stack+0x10/0x14
>> ...
>>
>> ARM64 also takes care of it in dump_backtrace(), so same logic
>> is added for ARM also.
>>
>> Fixes: 18ed1c01a7dd ("ARM: smp: Enable THREAD_INFO_IN_TASK")
>> Signed-off-by: Maninder Singh <maninder1.s@samsung.com>


Thanks,
Maninder Singh

RE: [PATCH 1/1] arm: get task_stack reference before dump_backtrace

[Maninder Singh]

> So It has to be same way for all archs, as mentioned in Help of THREAD_INFO_IN_TASK
> 
> config THREAD_INFO_IN_TASK
>         bool
>         help
>           Select this to move thread_info off the stack into task_struct.  To
>           make this work, an arch will need to remove all thread_info fields
>           except flags and fix any runtime bugs.
> 
>           One subtle change that will be needed is to use try_get_task_stack()
>           and put_task_stack() in save_thread_stack_tsk() and save_thread_stack_tsk().
> 
> alongwith save_thread_stack_tsk and save_thread_stack_tsk, same thing shall be done for show_stack also.

Typo error:

config THREAD_INFO_IN_TASK
        bool
        help
          Select this to move thread_info off the stack into task_struct.  To
          make this work, an arch will need to remove all thread_info fields
          except flags and fix any runtime bugs.

          One subtle change that will be needed is to use try_get_task_stack()
          and put_task_stack() in save_thread_stack_tsk() and get_wchan().

alongwith save_thread_stack_tsk() and get_wchan(), same thing shall be done for show_stack() also.