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

Message-ID: <alpine.DEB.2.11.1509101127420.9501@east.gentwo.org>
Date:	Thu, 10 Sep 2015 11:30:31 -0500 (CDT)
From:	Christoph Lameter <cl@...ux.com>
To:	Nikolay Borisov <kernel@...p.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 Thu, 10 Sep 2015, Nikolay Borisov wrote:

> > 	echo 1 >santy_checks
>
> [root@...nighan linux-stable]# cd /sys/kernel/slab/kmalloc-32/
> [root@...nighan kmalloc-32]# echo 1 > sanity_checks
> [root@...nighan kmalloc-32]# cat sanity_checks
> 1
>
> So this works as expected when set by echo. Just for testing I then
> tried the following:
> [root@...nighan kmalloc-32]# slabinfo -d- kmalloc-32
> kmalloc-32 not empty cannot disable sanity checks
>
> [root@...nighan kmalloc-32]# echo 0 > sanity_checks
> [root@...nighan kmalloc-32]# slabinfo -d- kmalloc-32
>
> So turns out slabinfo fails where the raw sys interface succeeds, strange?

Weird. slabinfo needs fixing.

> > do? Could crash the sysem due to overload of messages.
>
> Didn't have that much luck with this one:
> [root@...nighan kmalloc-32]# dmesg -c > /dev/null
> [root@...nighan kmalloc-32]# echo 1 > trace
> -bash: echo: write error: Invalid argument


Huh? There is no check that I am ware of in the slab code that would
return -EINVAL.

> > Sanity checking is ok. But I would think you should be fine with enabling
> > full debugging on the particular caches of interest.
>
> I was just thinking that if enabling debug options disables merging this
> means it won't be sufficient to enable debugging on kmalloc-32 but
> rather before enabling debugging I do need to check which caches were
> aliased and enable debugging on those as well, correct?

Correct.

--
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/