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]

Message-ID: <55F11F4E.4030703@kyup.com>
Date:	Thu, 10 Sep 2015 09:12:30 +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/09/2015 05:01 PM, Christoph Lameter wrote:
> On Wed, 9 Sep 2015, Nikolay Borisov wrote:
> 
>> [root@...nighan vm]# ./slabinfo -da kmalloc-32
>> Cannot write to dma-kmalloc-32/sanity
>> [root@...nighan vm]# ./slabinfo -dF kmalloc-32
>> Cannot write to dma-kmalloc-32/sanity
>> [root@...nighan vm]# ./slabinfo -dz kmalloc-32
>> kmalloc-32 not empty cannot enable redzoning
>> [root@...nighan vm]# ./slabinfo -dp kmalloc-32
>> kmalloc-32 not empty cannot enable poisoning
>> [root@...nighan vm]# ./slabinfo -du kmalloc-32
>> kmalloc-32 not empty cannot enable tracking
>> [root@...nighan vm]# ./slabinfo -dt ^kmalloc-32$
>> kmalloc-32 can only enable trace for one slab at a time
> 
> 
> Hmmmm.. Whats the problem here?
> 
> christoph@...two:/sys/kernel/slab/kmalloc-32$ ls -l
> total 0
> -r-------- 1 root root 4096 Sep  9 08:57 aliases
> -r-------- 1 root root 4096 Sep  9 08:57 align
> -r-------- 1 root root 4096 Sep  9 08:57 alloc_calls
> -r-------- 1 root root 4096 Sep  9 08:57 cache_dma
> -rw------- 1 root root 4096 Sep  9 08:57 cpu_partial
> -r-------- 1 root root 4096 Sep  9 08:57 cpu_slabs
> -r-------- 1 root root 4096 Sep  9 08:57 ctor
> -r-------- 1 root root 4096 Sep  9 08:57 destroy_by_rcu
> -r-------- 1 root root 4096 Sep  9 08:57 free_calls
> -r-------- 1 root root 4096 Sep  9 08:57 hwcache_align
> -rw------- 1 root root 4096 Sep  9 08:57 min_partial
> -r-------- 1 root root 4096 Sep  9 08:57 objects
> -r-------- 1 root root 4096 Sep  9 08:57 object_size
> -r-------- 1 root root 4096 Sep  9 08:57 objects_partial
> -r-------- 1 root root 4096 Sep  9 08:57 objs_per_slab
> -rw------- 1 root root 4096 Sep  9 08:57 order
> -r-------- 1 root root 4096 Sep  9 08:57 partial
> -rw------- 1 root root 4096 Sep  9 08:57 poison
> -rw------- 1 root root 4096 Sep  9 08:57 reclaim_account
> -rw------- 1 root root 4096 Sep  9 08:57 red_zone
> -rw------- 1 root root 4096 Sep  9 08:57 remote_node_defrag_ratio
> -r-------- 1 root root 4096 Sep  9 08:57 reserved
> -rw------- 1 root root 4096 Sep  9 08:57 sanity_checks
> -rw------- 1 root root 4096 Sep  9 08:57 shrink
> -r-------- 1 root root 4096 Sep  9 08:57 slabs
> -r-------- 1 root root 4096 Sep  9 08:57 slabs_cpu_partial
> -r-------- 1 root root 4096 Sep  9 08:57 slab_size
> -rw------- 1 root root 4096 Sep  9 08:57 store_user
> -r-------- 1 root root 4096 Sep  9 08:57 total_objects
> -rw------- 1 root root 4096 Sep  9 08:57 trace
> -rw------- 1 root root 4096 Sep  9 08:57 validate
> 
> Try
> 
> 	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?



> 
> 
>>
>> I did however had success with enabling tracing but couldn't see where
>> the output is produced - tried dmesg and the ftrace buffer but nothing
>> turned up.
> 
> dmesg is the output channel for tracing.
> 
> What does:
> 
> 	echo 1 >trace
> 
> 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

> 
>> But it seems it is not possible to enable any debugging whatsoever, so I
>> will restor to doing it at boot time. In this case can you advice which
>> options might not result in very high performance degradation - I'm
>> thinking of sanity checking and maybe redzoning?
> 
> 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?


Regards,
Nikolay
--
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/