Skip to contentSkip to conversation

Patch "arm64: fix dump_backtrace/unwind_frame with NULL tsk" has been added to the 4.8-stable tree

PATCH [email protected] 1 participant 1 message Oct 14, 2016

Subsystems (2)
lore
Share & tools
lore

[email protected]

author maintainer Applied
#0 lore raw

This is a note to let you know that I've just added the patch titled

arm64: fix dump_backtrace/unwind_frame with NULL tsk

to the 4.8-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
arm64-fix-dump_backtrace-unwind_frame-with-null-tsk.patch
and it can be found in the queue-4.8 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree, please let <[email protected]> know about it.

Quoted 1 line

From b5e7307d9d5a340d2c9fabbe1cee137d4c682c71 Mon Sep 17 00:00:00 2001

From: Mark Rutland <[email protected]>
Date: Fri, 23 Sep 2016 17:55:05 +0100
Subject: arm64: fix dump_backtrace/unwind_frame with NULL tsk

From: Mark Rutland <[email protected]>

commit b5e7307d9d5a340d2c9fabbe1cee137d4c682c71 upstream.

In some places, dump_backtrace() is called with a NULL tsk parameter, e.g. in bug_handler() in arch/arm64, or indirectly via show_stack() in core code. The expectation is that this is treated as if current were passed instead of NULL. Similar is true of unwind_frame().

Commit a80a0eb70c358f8c ("arm64: make irq_stack_ptr more robust") didn't take this into account. In dump_backtrace() it compares tsk against current *before* we check if tsk is NULL, and in unwind_frame() we never set tsk if it is NULL.

Due to this, we won't initialise irq_stack_ptr in either function. In dump_backtrace() this results in calling dump_mem() for memory immediately above the IRQ stack range, rather than for the relevant range on the task stack. In unwind_frame we'll reject unwinding frames on the IRQ stack.

In either case this results in incomplete or misleading backtrace information, but is not otherwise problematic. The initial percpu areas (including the IRQ stacks) are allocated in the linear map, and dump_mem uses __get_user(), so we shouldn't access anything with side-effects, and will handle holes safely.

This patch fixes the issue by having both functions handle the NULL tsk case before doing anything else with tsk.

Fixes a80a0eb70c358f8c ("arm64: make irq_stack_ptr more robust")
Cc Catalin Marinas <[email protected]>
Cc Will Deacon <[email protected]>
Cc Yang Shi <[email protected]>
---
 arch/arm64/kernel/stacktrace.c |    5 ++++-
 arch/arm64/kernel/traps.c      |   10 +++++-----
 2 files changed, 9 insertions(+), 6 deletions(-)
arch/arm64/kernel/stacktrace.c +4 -1
@@ -43,6 +43,9 @@ int notrace unwind_frame(struct task_str
 	unsigned long fp = frame->fp;
 	unsigned long irq_stack_ptr;
 
+	if (!tsk)
+		tsk = current;
+
 	/*
 	 * Switching between stacks is valid when tracing current and in
 	 * non-preemptible context.
@@ -67,7 +70,7 @@ int notrace unwind_frame(struct task_str
 	frame->pc = READ_ONCE_NOCHECK(*(unsigned long *)(fp + 8));
 
 #ifdef CONFIG_FUNCTION_GRAPH_TRACER
-	if (tsk && tsk->ret_stack &&
+	if (tsk->ret_stack &&
 			(frame->pc == (unsigned long)return_to_handler)) {
 		/*
 		 * This is a case where function graph tracer has
arch/arm64/kernel/traps.c +5 -5
@@ -142,6 +142,11 @@ static void dump_backtrace(struct pt_reg
 	unsigned long irq_stack_ptr;
 	int skip;
 
+	pr_debug("%s(regs = %p tsk = %p)\n", __func__, regs, tsk);
+
+	if (!tsk)
+		tsk = current;
+
 	/*
 	 * Switching between stacks is valid when tracing current and in
 	 * non-preemptible context.
@@ -151,11 +156,6 @@ static void dump_backtrace(struct pt_reg
 	else
 		irq_stack_ptr = 0;
 
-	pr_debug("%s(regs = %p tsk = %p)\n", __func__, regs, tsk);
-
-	if (!tsk)
-		tsk = current;
-
 	if (tsk == current) {
 		frame.fp = (unsigned long)__builtin_frame_address(0);
 		frame.sp = current_stack_pointer;

Patches currently in stable-queue which might be from [email protected] are

queue-4.8/arm64-fix-dump_backtrace-unwind_frame-with-null-tsk.patch