linux-stable.git/arch/x86/kernel/dumpstack.c, branch linux-5.4.y

x86/dumpstack: Fix inaccurate unwinding from exception stacks due to misplaced assignment

2025-04-10T12:29:41+00:00

[ Upstream commit 2c118f50d7fd4d9aefc4533a26f83338b2906b7a ]

Commit:

  2e4be0d011f2 ("x86/show_trace_log_lvl: Ensure stack pointer is aligned, again")

was intended to ensure alignment of the stack pointer; but it also moved
the initialization of the "stack" variable down into the loop header.

This was likely intended as a no-op cleanup, since the commit
message does not mention it; however, this caused a behavioral change
because the value of "regs" is different between the two places.

Originally, get_stack_pointer() used the regs provided by the caller; after
that commit, get_stack_pointer() instead uses the regs at the top of the
stack frame the unwinder is looking at. Often, there are no such regs at
all, and "regs" is NULL, causing get_stack_pointer() to fall back to the
task's current stack pointer, which is not what we want here, but probably
happens to mostly work. Other times, the original regs will point to
another regs frame - in that case, the linear guess unwind logic in
show_trace_log_lvl() will start unwinding too far up the stack, causing the
first frame found by the proper unwinder to never be visited, resulting in
a stack trace consisting purely of guess lines.

Fix it by moving the "stack = " assignment back where it belongs.

Fixes: 2e4be0d011f2 ("x86/show_trace_log_lvl: Ensure stack pointer is aligned, again")
Signed-off-by: Jann Horn 
Signed-off-by: Ingo Molnar 
Link: https://lore.kernel.org/r/20250325-2025-03-unwind-fixes-v1-2-acd774364768@google.com
Signed-off-by: Sasha Levin

x86/show_trace_log_lvl: Ensure stack pointer is aligned, again

2023-05-30T11:44:10+00:00

commit 2e4be0d011f21593c6b316806779ba1eba2cd7e0 upstream.

The commit e335bb51cc15 ("x86/unwind: Ensure stack pointer is aligned")
tried to align the stack pointer in show_trace_log_lvl(), otherwise the
"stack < stack_info.end" check can't guarantee that the last read does
not go past the end of the stack.

However, we have the same problem with the initial value of the stack
pointer, it can also be unaligned. So without this patch this trivial
kernel module

	#include 

	static int init(void)
	{
		asm volatile("sub    $0x4,%rsp");
		dump_stack();
		asm volatile("add    $0x4,%rsp");

		return -EAGAIN;
	}

	module_init(init);
	MODULE_LICENSE("GPL");

crashes the kernel.

Fixes: e335bb51cc15 ("x86/unwind: Ensure stack pointer is aligned")
Signed-off-by: Vernon Lovejoy 
Signed-off-by: Oleg Nesterov 
Link: https://lore.kernel.org/r/20230512104232.GA10227@redhat.com
Signed-off-by: Josh Poimboeuf 
Signed-off-by: Greg Kroah-Hartman

exit: Add and use make_task_dead.

2023-02-06T06:52:49+00:00

commit 0e25498f8cd43c1b5aa327f373dd094e9a006da7 upstream.

There are two big uses of do_exit.  The first is it's design use to be
the guts of the exit(2) system call.  The second use is to terminate
a task after something catastrophic has happened like a NULL pointer
in kernel code.

Add a function make_task_dead that is initialy exactly the same as
do_exit to cover the cases where do_exit is called to handle
catastrophic failure.  In time this can probably be reduced to just a
light wrapper around do_task_dead. For now keep it exactly the same so
that there will be no behavioral differences introducing this new
concept.

Replace all of the uses of do_exit that use it for catastraphic
task cleanup with make_task_dead to make it clear what the code
is doing.

As part of this rename rewind_stack_do_exit
rewind_stack_and_make_dead.

Signed-off-by: "Eric W. Biederman" 
Signed-off-by: Eric Biggers 
Signed-off-by: Sasha Levin

x86/dumpstack: Indicate PREEMPT_RT in dumps

2019-07-31T17:03:36+00:00

Stack dumps print whether the kernel has preemption enabled or not. Extend
it so a PREEMPT_RT enabled kernel can be identified.

Signed-off-by: Thomas Gleixner 
Acked-by: Peter Zijlstra (Intel) 
Cc: Linus Torvalds 
Cc: Masami Hiramatsu 
Cc: Paolo Bonzini 
Cc: Paul E. McKenney 
Cc: Peter Zijlstra 
Cc: Steven Rostedt 
Link: http://lkml.kernel.org/r/20190726212124.699136351@linutronix.de
Signed-off-by: Ingo Molnar

x86/process: Don't mix user/kernel regs in 64bit __show_regs()

2018-09-06T12:33:12+00:00

When the kernel.print-fatal-signals sysctl has been enabled, a simple
userspace crash will cause the kernel to write a crash dump that contains,
among other things, the kernel gsbase into dmesg.

As suggested by Andy, limit output to pt_regs, FS_BASE and KERNEL_GS_BASE
in this case.

This also moves the bitness-specific logic from show_regs() into
process_{32,64}.c.

Fixes: 45807a1df9f5 ("vdso: print fatal signals")
Signed-off-by: Jann Horn 
Signed-off-by: Thomas Gleixner 
Cc: "H. Peter Anvin" 
Cc: Andy Lutomirski 
Cc: Borislav Petkov 
Cc: Greg Kroah-Hartman 
Cc: stable@vger.kernel.org
Link: https://lkml.kernel.org/r/20180831194151.123586-1-jannh@google.com

x86/dumpstack: Don't dump kernel memory based on usermode RIP

2018-08-31T15:08:22+00:00

show_opcodes() is used both for dumping kernel instructions and for dumping
user instructions. If userspace causes #PF by jumping to a kernel address,
show_opcodes() can be reached with regs->ip controlled by the user,
pointing to kernel code. Make sure that userspace can't trick us into
dumping kernel memory into dmesg.

Fixes: 7cccf0725cf7 ("x86/dumpstack: Add a show_ip() function")
Signed-off-by: Jann Horn 
Signed-off-by: Thomas Gleixner 
Reviewed-by: Kees Cook 
Reviewed-by: Borislav Petkov 
Cc: "H. Peter Anvin" 
Cc: Andy Lutomirski 
Cc: security@kernel.org
Cc: stable@vger.kernel.org
Link: https://lkml.kernel.org/r/20180828154901.112726-1-jannh@google.com

x86/entry/64: Wipe KASAN stack shadow before rewind_stack_do_exit()

2018-08-30T09:37:09+00:00

Reset the KASAN shadow state of the task stack before rewinding RSP.
Without this, a kernel oops will leave parts of the stack poisoned, and
code running under do_exit() can trip over such poisoned regions and cause
nonsensical false-positive KASAN reports about stack-out-of-bounds bugs.

This does not wipe the exception stacks; if an oops happens on an exception
stack, it might result in random KASAN false-positives from other tasks
afterwards. This is probably relatively uninteresting, since if the kernel
oopses on an exception stack, there are most likely bigger things to worry
about. It'd be more interesting if vmapped stacks and KASAN were
compatible, since then handle_stack_overflow() would oops from exception
stack context.

Fixes: 2deb4be28077 ("x86/dumpstack: When OOPSing, rewind the stack before do_exit()")
Signed-off-by: Jann Horn 
Signed-off-by: Thomas Gleixner 
Acked-by: Andrey Ryabinin 
Cc: Andy Lutomirski 
Cc: Dmitry Vyukov 
Cc: Alexander Potapenko 
Cc: Kees Cook 
Cc: kasan-dev@googlegroups.com
Cc: stable@vger.kernel.org
Link: https://lkml.kernel.org/r/20180828184033.93712-1-jannh@google.com

x86: Avoid pr_cont() in show_opcodes()

2018-07-19T14:46:23+00:00

If concurrent printk() messages are emitted, then pr_cont() is making it
extremly hard to decode which part of the output belongs to what. See the
convoluted example at:

  https://syzkaller.appspot.com/text?tag=CrashReport&x=139d342c400000

Avoid this by using a proper prefix for each line and by using %ph format
in show_opcodes() which emits the 'Code:' line in one go.

Signed-off-by: Rasmus Villemoes 
Signed-off-by: Tetsuo Handa 
Signed-off-by: Thomas Gleixner 
Acked-by: Peter Zijlstra (Intel) 
Cc: joe@perches.com
Cc: Andy Lutomirski 
Cc: Borislav Petkov 
Cc: Josh Poimboeuf 
Cc: Linus Torvalds 
Link: https://lkml.kernel.org/r/1532009278-5953-1-git-send-email-penguin-kernel@I-love.SAKURA.ne.jp

x86/dumpstack: Explain the reasoning for the prologue and buffer size

2018-04-26T14:15:28+00:00

The whole reasoning behind the amount of opcode bytes dumped and prologue
length isn't very clear so write down some of the reasons for why it is
done the way it is.

Signed-off-by: Borislav Petkov 
Signed-off-by: Thomas Gleixner 
Cc: Peter Zijlstra 
Cc: Josh Poimboeuf 
Cc: Linus Torvalds 
Cc: Andy Lutomirski 
Link: https://lkml.kernel.org/r/20180417161124.5294-10-bp@alien8.de

x86/dumpstack: Save first regs set for the executive summary

2018-04-26T14:15:28+00:00

Save the regs set when __die() is onvoked for the first time and print it
in oops_end().

Signed-off-by: Borislav Petkov 
Signed-off-by: Thomas Gleixner 
Cc: Peter Zijlstra 
Cc: Josh Poimboeuf 
Cc: Linus Torvalds 
Cc: Andy Lutomirski 
Link: https://lkml.kernel.org/r/20180417161124.5294-9-bp@alien8.de