linux-kernel - Re: [lkp-robot] [x86/kconfig] 81d3871900: BUG:unable_to_handle

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]

Message-ID: <alpine.DEB.2.20.1710131021240.3949@nuc-kabylake>
Date:   Fri, 13 Oct 2017 10:22:54 -0500 (CDT)
From:   Christopher Lameter <cl@...ux.com>
To:     Josh Poimboeuf <jpoimboe@...hat.com>
cc:     kernel test robot <xiaolong.ye@...el.com>,
        Ingo Molnar <mingo@...nel.org>,
        Andy Lutomirski <luto@...nel.org>,
        Borislav Petkov <bp@...en8.de>,
        Brian Gerst <brgerst@...il.com>,
        Denys Vlasenko <dvlasenk@...hat.com>,
        "H. Peter Anvin" <hpa@...or.com>, Jiri Slaby <jslaby@...e.cz>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Mike Galbraith <efault@....de>,
        Peter Zijlstra <peterz@...radead.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        LKML <linux-kernel@...r.kernel.org>, lkp@...org,
        linux-mm@...ck.org, Pekka Enberg <penberg@...nel.org>,
        David Rientjes <rientjes@...gle.com>,
        Joonsoo Kim <iamjoonsoo.kim@....com>,
        Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [lkp-robot] [x86/kconfig]  81d3871900:
 BUG:unable_to_handle_kernel

On Thu, 12 Oct 2017, Josh Poimboeuf wrote:

> > Can you run SLUB with full debug? specify slub_debug on the commandline or
> > set CONFIG_SLUB_DEBUG_ON
>
> Oddly enough, with CONFIG_SLUB+slub_debug, I get the same crypto panic I
> got with CONFIG_SLOB.  The trapping instruction is:
>
>   vmovdqa 0x140(%rdi),%xmm0
>
> I'll try to bisect it tomorrow.  It at least goes back to v4.10.  I'm
> not really sure whether this panic is related to SLUB or SLOB at all.

Guess not. The slab allocators can fail if the metadata gets corrupted.
That is why we have extensive debug modes so we can find who is to blame
for corruptions.

> (Though the original panic reported upthread by the kernel test robot
> *does* look SLOB related.)

Yup. Just happened to be configured for SLOB then.