linux-kernel - [GIT PULL]

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Date:	Wed,  3 Mar 2010 04:09:02 +0100
From:	Frederic Weisbecker <fweisbec@...il.com>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	"H . Peter Anvin" <hpa@...or.com>,
	Peter Zijlstra <peterz@...radead.org>,
	Paul Mackerras <paulus@...ba.org>,
	Steven Rostedt <rostedt@...dmis.org>,
	"2 . 6 . 33 . x" <stable@...nel.org>,
	Arnaldo Carvalho de Melo <acme@...hat.com>
Subject: [GIT PULL] 

Ingo,

Please pull the perf/urgent branch that can be found at:

git://git.kernel.org/pub/scm/linux/kernel/git/frederic/random-tracing.git
	perf/urgent

Thanks,
	Frederic
---

Frederic Weisbecker (1):
      x86/stacktrace: Don't dereference bad frame pointers


 arch/x86/kernel/dumpstack_64.c |   12 +++++++++---
 1 files changed, 9 insertions(+), 3 deletions(-)

---
commit 29044ad1509ecc229f1d5a31aeed7a8dc61a71c4
Author: Frederic Weisbecker <fweisbec@...il.com>
Date:   Wed Mar 3 02:25:22 2010 +0100

    x86/stacktrace: Don't dereference bad frame pointers
    
    Callers of a stacktrace might pass bad frame pointers. Those
    are usually checked for safety in stack walking helpers before
    any dereferencing, but this is not the case when we need to go
    through one more frame pointer that backlinks the irq stack to
    the previous one, as we don't have any reliable address boudaries
    to compare this frame pointer against.
    
    This raises crashes when we record callchains for ftrace events
    with perf because we don't use the right helpers to capture
    registers there. We get wrong frame pointers as we call
    task_pt_regs() even on kernel threads, which is a wrong thing
    as it gives us the initial state of any kernel threads freshly
    created. This is even not what we want for user tasks. What we want
    is a hot snapshot of registers when the ftrace event triggers, not
    the state before a task entered the kernel.
    
    This requires more thoughts to do it correctly though.
    So first put a guardian to ensure the given frame pointer
    can be dereferenced to avoid crashes. We'll think about how to fix
    the callers in a subsequent patch.
    
    Signed-off-by: Frederic Weisbecker <fweisbec@...il.com>
    Cc: Ingo Molnar <mingo@...e.hu>
    Cc: Thomas Gleixner <tglx@...utronix.de>
    Cc: H. Peter Anvin <hpa@...or.com>
    Cc: Peter Zijlstra <peterz@...radead.org>
    Cc: Paul Mackerras <paulus@...ba.org>
    Cc: Steven Rostedt <rostedt@...dmis.org>
    Cc: 2.6.33.x <stable@...nel.org>
    Cc: Arnaldo Carvalho de Melo <acme@...hat.com>

diff --git a/arch/x86/kernel/dumpstack_64.c b/arch/x86/kernel/dumpstack_64.c
index 0ad9597..a6c906c 100644
--- a/arch/x86/kernel/dumpstack_64.c
+++ b/arch/x86/kernel/dumpstack_64.c
@@ -125,9 +125,15 @@ fixup_bp_irq_link(unsigned long bp, unsigned long *stack,
 {
 #ifdef CONFIG_FRAME_POINTER
 	struct stack_frame *frame = (struct stack_frame *)bp;
+	unsigned long next;
 
-	if (!in_irq_stack(stack, irq_stack, irq_stack_end))
-		return (unsigned long)frame->next_frame;
+	if (!in_irq_stack(stack, irq_stack, irq_stack_end)) {
+		if (!probe_kernel_address(&frame->next_frame, next))
+			return next;
+		else
+			WARN_ONCE(1, "Perf: bad frame pointer = %p in "
+				  "callchain\n", &frame->next_frame);
+	}
 #endif
 	return bp;
 }
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/