| 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
| ||
|
Date: Wed, 9 Sep 2015 09:01:10 -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 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 > > 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. > 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. -- 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/
Powered by blists - more mailing lists