linux-kernel - Re: v4.10: kernel stack frame pointer .. has bad value (null)

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>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 21 Feb 2017 15:15:36 -0800
From:   "H. Peter Anvin" <hpa@...or.com>
To:     Josh Poimboeuf <jpoimboe@...hat.com>, Pavel Machek <pavel@....cz>
Cc:     kernel list <linux-kernel@...r.kernel.org>, mingo@...nel.org,
        luto@...nel.org, bp@...en8.de, brgerst@...il.com,
        dvlasenk@...hat.com, torvalds@...ux-foundation.org,
        peterz@...radead.org, tglx@...utronix.de
Subject: Re: v4.10: kernel stack frame pointer .. has bad value (null)

On 02/21/17 15:12, Josh Poimboeuf wrote:
>>
>> commit 24d86f59093b0bcb3756cdf47f2db10ff4e90dbb
>> Author: Josh Poimboeuf <jpoimboe@...hat.com>
>> Date:   Thu Oct 27 08:10:58 2016 -0500
>>
>>     x86/unwind: Ensure stack grows down
>>
>>     Add a sanity check to ensure the stack only grows down, and print
>>     a
>>         warning if the check fails.
>>
>> Any ideas?
> 
> Hi Pavel,
> 
> I don't think I've seen this one.  Any chance this came after resuming
> from a hibernation or suspend?
> 
> 
>> [    1.047295] [drm] Memory usable by graphics device = 2048M
>> [    1.047356] [drm] Replacing VGA console driver
>> [    1.048029] Console: switching to colour dummy device 80x25
>> [    1.048348] WARNING: kernel stack frame pointer at f50cdf98 in
>> swapper/2:0 has bad value   (null)
>> [    1.048349] unwind stack type:0 next_sp:  (null) mask:a graph_idx:0
>> [    1.048352] f50cdebc: 00000000f50cdec4 (0xf50cdec4)
                            ^^^^^^^^^^^^^^^^

FWIW, it would be really darned nice to not have all those zeroes in a
32-bit stack frame dump.

Is not a zero stack frame pointer value an end of stack token?

	-hpa