linux-ext4 - Re: Repeatable ext4 oops with 3.6.0 (regression)

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: <20121004173425.GA15405@thunk.org>
Date:	Thu, 4 Oct 2012 13:34:25 -0400
From:	Theodore Ts'o <tytso@....edu>
To:	Holger Hoffstätte 
	<holger.hoffstaette@...glemail.com>
Cc:	Jan Kara <jack@...e.cz>, linux-ext4@...r.kernel.org,
	linux-mm@...ck.org
Subject: Re: Repeatable ext4 oops with 3.6.0 (regression)

On Thu, Oct 04, 2012 at 05:31:41PM +0200, Holger Hoffstätte wrote:

> So armed with multiple running shells I finally managed to save the dmesg
> to NFS. It doesn't get any more complete than this and again shows the
> ext4 stacktrace from before. So maybe it really is generic kmem corruption
> and ext4 looking at symlinks/inodes is just the victim.

That certainly seems to be the case.  As near as I can tell from the
stack trace, you're doing a readdir(), and the crash is happening in
ext4_htree_store_dirent() --- the stack address to ext4_follow_link()
makes no sense given the rest of the strack trace, and anyway,
ext4_follow_link() doesn't do any memory allocation.

So that means this:
> [  106.643048]  [<c0236ed9>] ext4_htree_store_dirent+0x29/0x110

Almost certainly corresponds to the following call to kzalloc:

	/* Create and allocate the fname structure */
	len = sizeof(struct fname) + dirent->name_len + 1;
	new_fn = kzalloc(len, GFP_KERNEL);

dirent->name_len is a unsigned char, and struct fname is around 48
bytes or so.  So len is never going to be larger than 300 bytes, and
never smaller than 48 bytes, which is certainly valid input as far as
kzalloc() is concerned.

So it's very likely that the crash in __kmalloc() is probably caused
by the internal slab/slub data structures getting scrambled.

Regards,

					- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html