linux-kernel - Re: Kernel 4.1.6 Panic due to slab corruption

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, 8 Sep 2015 17:41:53 +0300
From:	Nikolay Borisov <kernel@...p.com>
To:	Christoph Lameter <cl@...ux.com>
Cc:	"Linux-Kernel@...r. Kernel. Org" <linux-kernel@...r.kernel.org>,
	Marian Marinov <mm@...com>,
	SiteGround Operations <operations@...eground.com>
Subject: Re: Kernel 4.1.6 Panic due to slab corruption



On 09/08/2015 05:27 PM, Christoph Lameter wrote:
> On Tue, 8 Sep 2015, Nikolay Borisov wrote:
> 
>> Unfortunately I haven't found a way to reproduce it so the only option
>> would be to do this on a live server. However, the performance impact I
>> believe is going to be very prohibitive :(.  Alternatively what I could
>> do is probably leave merging on but enable debugging only for the
>> kmalloc-32 slab cache. Do you think this would provide enough
>> information to help track the corruption when it happens, without
>> impacting performance?
> 
> You have read https://www.kernel.org/doc/Documentation/vm/slub.txt?

I've read that I'm also following the merge/nomerge thread on the DM
mailing list. I guess my understanding is wrong in that if multiple slab
caches are merged, then it's enough to just instrument the cache to
which they are being merge in order to have them all instrumented? I
guess that's not the case, so even though slab caches might be merge
they are still somehow considered different entities in the kernel?

> 
> 
> The problem now is that merging is on so it could be that the corruption
> happens in one of the aliased caches. So maybe only kmalloc-32 wont do
> much good.
> 
> Run
> 
> 	slabinfo -a
> 
> (slabinfo.c is a tool in the kernel tree.)
> 
> to see the list of aliases for kmalloc-32.
> 
> You can also use slabinfo to enable some debugging at runtime. Just
> enabling sanity checks may catch something that allows us to track this to
> the subsystem.

I will experiment with slabinfo.
--
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/