linux-toradex.git/arch/arm/kernel/stacktrace.c, branch v5.7-rc6

ARM: 8948/1: Prevent OOB access in stacktrace

2020-01-25T18:18:11+00:00

The stacktrace code can read beyond the stack size, when it attempts to
read pt_regs from exception frames.

This can happen on normal, non-corrupt stacks.  Since the unwind
information in the extable is not correct for function prologues, the
unwinding code can return data from the stack which is not actually the
caller function address, and if in_entry_text() happens to succeed on
this value, we can end up reading data from outside the task's stack
when attempting to read pt_regs, since there is no bounds check.

Example:

 [<8010e729>] (unwind_backtrace) from [<8010a9c9>] (show_stack+0x11/0x14)
 [<8010a9c9>] (show_stack) from [<8057d8d7>] (dump_stack+0x87/0xac)
 [<8057d8d7>] (dump_stack) from [<8012271d>] (tasklet_action_common.constprop.4+0xa5/0xa8)
 [<8012271d>] (tasklet_action_common.constprop.4) from [<80102333>] (__do_softirq+0x11b/0x31c)
 [<80102333>] (__do_softirq) from [<80122485>] (irq_exit+0xad/0xd8)
 [<80122485>] (irq_exit) from [<8015f3d7>] (__handle_domain_irq+0x47/0x84)
 [<8015f3d7>] (__handle_domain_irq) from [<8036a523>] (gic_handle_irq+0x43/0x78)
 [<8036a523>] (gic_handle_irq) from [<80101a49>] (__irq_svc+0x69/0xb4)
 Exception stack(0xeb491f58 to 0xeb491fa0)
 1f40:                                                       7eb14794 00000000
 1f60: ffffffff 008dd32c 008dd324 ffffffff 008dd314 0000002a 801011e4 eb490000
 1f80: 0000002a 7eb1478c 50c5387d eb491fa8 80101001 8023d09c 40080033 ffffffff
 [<80101a49>] (__irq_svc) from [<8023d09c>] (do_pipe2+0x0/0xac)
 [<8023d09c>] (do_pipe2) from [] (0xffffffff)
 Exception stack(0xeb491fc8 to 0xeb492010)
 1fc0:                   008dd314 0000002a 00511ad8 008de4c8 7eb14790 7eb1478c
 1fe0: 00511e34 7eb14774 004c8557 76f44098 60080030 7eb14794 00000000 00000000
 2000: 00000001 00000000 ea846c00 ea847cc0

In this example, the stack limit is 0xeb492000, but 16 bytes outside the
stack have been read.

Fix it by adding bounds checks.

Signed-off-by: Vincent Whitchurch 
Signed-off-by: Russell King

treewide: Add SPDX license identifier for missed files

2019-05-21T08:50:45+00:00

Add SPDX license identifiers to all files which:

 - Have no license information of any form

 - Have EXPORT_.*_SYMBOL_GPL inside which was used in the
   initial scan/conversion to ignore the file

These files fall under the project license, GPL v2 only. The resulting SPDX
license identifier is:

  GPL-2.0-only

Signed-off-by: Thomas Gleixner 
Signed-off-by: Greg Kroah-Hartman

arm/stacktrace: Remove the pointless ULONG_MAX marker

2019-04-14T17:58:27+00:00

Terminating the last trace entry with ULONG_MAX is a completely pointless
exercise and none of the consumers can rely on it because it's
inconsistently implemented across architectures. In fact quite some of the
callers remove the entry and adjust stack_trace.nr_entries afterwards.

Signed-off-by: Thomas Gleixner 
Acked-by: Peter Zijlstra (Intel) 
Cc: Josh Poimboeuf 
Cc: Andy Lutomirski 
Cc: Steven Rostedt 
Cc: Alexander Potapenko 
Cc: Russell King 
Cc: linux-arm-kernel@lists.infradead.org
Link: https://lkml.kernel.org/r/20190410103643.843075256@linutronix.de

ARM: probes: avoid adding kprobes to sensitive kernel-entry/exit code

2017-12-17T22:14:21+00:00

Avoid adding kprobes to any of the kernel entry/exit or startup
assembly code, or code in the identity-mapped region.  This code does
not conform to the standard C conventions, which means that the
expectations of the kprobes code is not forfilled.

Placing kprobes at some of these locations results in the kernel trying
to return to userspace addresses while retaining the CPU in kernel mode.

Tested-by: Naresh Kamboju 
Signed-off-by: Russell King

ARM: 8691/1: Export save_stack_trace_tsk()

2017-09-09T15:26:42+00:00

The kernel watchdog is a great debugging tool for finding tasks that
consume a disproportionate amount of CPU time in contiguous chunks. One
can imagine building a similar watchdog for arbitrary driver threads
using save_stack_trace_tsk() and print_stack_trace(). However, this is
not viable for dynamically loaded driver modules on ARM platforms
because save_stack_trace_tsk() is not exported for those architectures.
Export save_stack_trace_tsk() for the ARM architecture to align with
x86 and support various debugging use cases such as arbitrary driver
thread watchdog timers.

Signed-off-by: Dustin Brown 
Signed-off-by: Russell King

sched/headers: Prepare for new header dependencies before moving code to

2017-03-02T07:42:34+00:00

We are going to split  out of , which
will have to be picked up from other headers and a couple of .c files.

Create a trivial placeholder  file that just
maps to  to make this patch obviously correct and
bisectable.

Include the new header in the files that are going to need it.

Acked-by: Linus Torvalds 
Cc: Mike Galbraith 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar

ARM: 8172/1: Use current_stack_pointer in save_stack_trace_tsk

2014-11-13T23:58:03+00:00

Use the global current_stack_pointer to get the value of the stack pointer.
This change supports being able to compile the kernel with both gcc and clang.

Signed-off-by: Behan Webster 
Reviewed-by: Mark Charlebois 
Reviewed-by: Jan-Simon Möller 
Acked-by: Will Deacon 
Acked-by: Nicolas Pitre 
Signed-off-by: Russell King

ARM: 8049/1: ftrace/add save_stack_trace_regs() implementation

2014-05-30T00:12:32+00:00

When configure kprobe events of ftrace with "stacktrace" option enabled
in arm, there is no stacktrace was recorded after the kprobe event was
triggered. The root cause is no save_stack_trace_regs() function implemented.

Implement the save_stack_trace_regs() function in arm, then ftrace will
call this architecture-related function to record the stacktrace into
ring buffer.

After this fix, stacktrace can be recorded, for example:

 # mount -t debugfs nodev /sys/kernel/debug
 # echo "p:netrx net_rx_action" >> /sys/kernel/debug/tracing/kprobe_events
 # echo 1 > /sys/kernel/debug/tracing/events/kprobes/netrx/enable
 # echo 1 > /sys/kernel/debug/tracing/options/stacktrace
 # echo 1 > /sys/kernel/debug/tracing/tracing_on
 # ping 127.0.0.1 -c 1
 # echo 0 > /sys/kernel/debug/tracing/tracing_on

 # cat /sys/kernel/debug/tracing/trace
 # tracer: nop
 #
 # entries-in-buffer/entries-written: 12/12   #P:1
 #
 #                              _-----=> irqs-off
 #                             / _----=> need-resched
 #                            | / _---=> hardirq/softirq
 #                            || / _--=> preempt-depth
 #                            ||| /     delay
 #           TASK-PID   CPU#  ||||    TIMESTAMP  FUNCTION
 #              | |       |   ||||       |         |
             <------ missing some entries ---------------->
             ping-1200  [000] dNs1   667.603250: netrx: (net_rx_action+0x0/0x1f8)
             ping-1200  [000] dNs1   667.604738: 
  => net_rx_action
  => do_softirq
  => local_bh_enable
  => ip_finish_output
  => ip_output
  => ip_local_out
  => ip_send_skb
  => ip_push_pending_frames
  => raw_sendmsg
  => inet_sendmsg
  => sock_sendmsg
  => SyS_sendto
  => ret_fast_syscall

Signed-off-by: Lin Yongting 
Acked-by: Steven Rostedt 
Signed-off-by: Russell King

ARM: stacktrace: include exception PC value in stacktrace output

2014-05-22T15:33:24+00:00

When we unwind through an exception stack, include the saved PC value
into the stack trace: this fills in an otherwise missed functions from
the trace (as indicated below):

 [] fec_enet_interrupt+0xa0/0xe8
 [] handle_irq_event_percpu+0x68/0x228
 [] handle_irq_event+0x4c/0x6c
 [] handle_fasteoi_irq+0xac/0x198
 [] generic_handle_irq+0x4c/0x60
 [] handle_IRQ+0x40/0x98
 [] gic_handle_irq+0x30/0x64
 [] __irq_svc+0x40/0x50
 [] __do_softirq+0xe0/0x2fc		<====
 [] irq_exit+0xb0/0x100
 [] handle_IRQ+0x44/0x98
 [] gic_handle_irq+0x30/0x64
 [] __irq_svc+0x40/0x50
 [] arch_cpu_idle+0x30/0x38		<====
 [] cpu_startup_entry+0xac/0x214
 [] rest_init+0x68/0x80
 [] start_kernel+0x2fc/0x358

Signed-off-by: Russell King

ARM: stacktrace: avoid listing stacktrace functions in stacktrace

2014-05-22T15:33:19+00:00

While debugging the FEC ethernet driver using stacktrace, it was noticed
that the stacktraces always begin as follows:

 [] save_stack_trace_tsk+0x0/0x98
 [] save_stack_trace+0x24/0x28
 ...

This is because the stack trace code includes the stack frames for itself.
This is incorrect behaviour, and also leads to "skip" doing the wrong
thing (which is the number of stack frames to avoid recording.)

Perversely, it does the right thing when passed a non-current thread.  Fix
this by ensuring that we have a known constant number of frames above the
main stack trace function, and always skip these.

Cc: 
Signed-off-by: Russell King