linux-kernel - Re: perf: perf_fuzzer quickly locks up on 4.15-rc7

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:   Thu, 11 Jan 2018 13:21:12 -0600
From:   Josh Poimboeuf <jpoimboe@...hat.com>
To:     Vince Weaver <vincent.weaver@...ne.edu>
Cc:     Peter Zijlstra <peterz@...radead.org>,
        Ingo Molnar <mingo@...nel.org>, linux-kernel@...r.kernel.org,
        Ingo Molnar <mingo@...hat.com>,
        Arnaldo Carvalho de Melo <acme@...nel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Andy Lutomirski <luto@...nel.org>
Subject: Re: perf: perf_fuzzer quickly locks up on 4.15-rc7

On Thu, Jan 11, 2018 at 02:00:27PM -0500, Vince Weaver wrote:
> On Wed, 10 Jan 2018, Josh Poimboeuf wrote:
> 
> > For the crash, you might try enabling CONFIG_DEBUG_ENTRY and seeing if
> > that gives you any output.
> 
> I did enable that, didn't seem to help on the haswell machien at least.
> 
> > > > > WARNING: can't dereference iret registers at 000000000783fea8 for ip paranoid_entry+0x2e/0x90
> > > > > WARNING: can't dereference registers at 00000000f0698d17 for ip paranoid_entry+0x4c/0x90
> > > > > WARNING: stack going in the wrong direction? ip=native_sched_clock+0x9/0x90
> > 
> > This all looks very weird.  The stack pointers -- 000000000783fea8 and
> > 00000000f0698d17 -- are obviously very wrong.  I will try to recreate
> > locally.
> 
> On a related note, on a core2 machine with the perf_fuzzer I got this too:
> 
> Jan 11 13:44:01 core2 kernel: [ 1078.931403] WARNING: stack recursion on stack type 4
> Jan 11 13:44:01 core2 kernel: [ 1078.931411] WARNING: can't dereference registers at 000000002c6beb99 for ip swapgs_restore_regs_and_return_to_usermode+0x2b/0x7c

Yuck.  This time it was stack recursion on the entry stack.  In the
previous error, recursion was detected on the IRQ stack.  Otherwise they
look quite similar.

Was that also with nopti?

I haven't had a chance to try it yet, any idea if these would be
recreatable in a VM?

-- 
Josh