[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080527140031.GA3380@alice>
Date: Tue, 27 May 2008 16:00:31 +0200
From: Eric Sesterhenn <snakebyte@....de>
To: linux-kernel@...r.kernel.org
Cc: vegardno@....uio.no, penberg@...helsinki.fi
Subject: Re: Redzone overwritten with CONFIG_SECURITY
hi,
i tested a kmemcheck kernel as an attempt to debug
this further... seems CONFIG_SECURITY is unrelated to
this, but slub debugging only catches the
overwrite it if i enable CONFIG_SECURITY.
with slub_debug=FZPU i get the warning at
init_object+0x63:
(gdb) l *(init_object+0x63)
0xc0187243 is in init_object (mm/slub.c:544).
539 {
540 u8 *p = object;
541
542 if (s->flags & __OBJECT_POISON) {
543 memset(p, POISON_FREE, s->objsize - 1);
544 p[s->objsize - 1] = POISON_END;
545 }
546
547 if (s->flags & SLAB_RED_ZONE)
548 memset(p + s->objsize,
if i set slub_debug=- i get the kmemcheck warning at
(gdb) l *(__slab_alloc+0x238)
0xc0187bc8 is in __slab_alloc (mm/slub.c:303).
298 return *(void **)(object + s->offset);
299 }
300
301 static inline void set_freepointer(struct kmem_cache *s, void
*object, void *fp)
302 {
303 *(void **)(object + s->offset) = fp;
304 }
305
306 /* Loop over all objects in a slab */
307 #define for_each_object(__p, __s, __addr, __objects) \
I used the kmemcheck git tree from
git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-kmemcheck-4.git
In case you need some of the other kmemcheck output please
let me know.
Greetings, Eric
* Eric Sesterhenn (snakebyte@....de) wrote:
> hi,
>
> i enabled CONFIG_SECURITY on current git and get tons of
> Redzone overwritten errors during early boot, even
> with CONFIG_SECURITY_CAPABILITIES and CONFIG_SECURITY_NETWORK
> disabled. After a while it ends with a kernel panic
> saying: not syncing: Out of memory and no killable process...
> Root partition is ext3 format.
>
> At the moment i dont have a camera at hand, so i'll try
> to write down everything which looks interesting, please tell
> me if i missed something.
>
> The first 24 Bytes of the overwritten section contain
> zeros. Then we have a constant 0x18, and three changing
> values. the next three bites contain exactly the same
> values, first the 0x18, then the two changing ones.
>
> The only value i found so far matching the 0x18 and
> which might be related to CONFIG_SECURITY is CAP_SYS_RESOURCE
> defined in /include/linux/capability.h
>
> BUG hugetlbfs_inode_cache: Redzone overwritten
>
> INFO: 0xccd8e250-0xccd8e253. First byte 0x0 instead of 0xbb
> Info: Slab 0xc119d1c0 objects=12 used=0 fs=0xccd8e000 flags=0x400020c3
> Info: Object 0xccd8e00 offset=0 fp=0xccd8e280
>
> Object 0xccd8e00: 00 00 00 ...
> Object 0xccd8e10: 00 00 00 00 00 00 00 00 00 18 e0 d8 cc 18 e0 d8 cc
> Object 0xccd8e20 00 00 00 ...
> ...
>
> Pid: 1, comm:swapper Not tainted 2.6.26-rc3-00436-gb373303 #42
> print_trailer
> check_bytes_and_report
> check_object
> __slab_alloc
> kmem_cache_alloc
> ? hugetlbfs_alloc_inode
> ? hugetlbfs_alloc_inode
> hugetlbfs_alloc_inode
> alloc_inote
> new_inode
> hugetlbs_get_inote
> hugetlbfs_fill_super
> ? sget
> ? set_anon_super
> get_sb_node
> hugetlbfs_get_sb
> ? hugetlbfs_fill_super
> vfs_kern_mount
> kern_mount_data
> init_hugetlbfs_fs
> ? init_once
> ? kernel_init
> kernel_init
--
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