linux-kernel - Re: [PATCH 2/2] x86/dumpstack: Fix broken unwinding from exception stacks

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 for Android: free password hash cracker in your pocket

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

Message-ID: <Z-Jb3xEcQWKn_uqe@gmail.com>
Date: Tue, 25 Mar 2025 08:31:43 +0100
From: Ingo Molnar <mingo@...nel.org>
To: Jann Horn <jannh@...gle.com>
Cc: x86@...nel.org, Andy Lutomirski <luto@...nel.org>,
	Josh Poimboeuf <jpoimboe@...nel.org>,
	Peter Zijlstra <peterz@...radead.org>, linux-kernel@...r.kernel.org,
	Dominik Brodowski <linux@...inikbrodowski.net>,
	Oleg Nesterov <oleg@...hat.com>,
	Vernon Lovejoy <vlovejoy@...hat.com>
Subject: Re: [PATCH 2/2] x86/dumpstack: Fix broken unwinding from exception
 stacks


* Jann Horn <jannh@...gle.com> wrote:

> On Tue, Mar 25, 2025 at 3:01 AM Jann Horn <jannh@...gle.com> wrote:
> > 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.
> 
> I guess the subject line is kind of misleading - maybe "x86/dumpstack:
> Fix misplaced assignment in unwinder" would be better?

Well, it's a bug and the code is broken that results in subpar stack 
dumps from exception contexts that fall back to the guess-dumper, 
right?

So I've edited the subject line to:

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

But I'd have no problem calling it broken either - even if the bug 
doesn't crash anything.

Thanks,

	Ingo