linux-kernel - Re: 2.6.39-rc5-git2 boot crashs

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]

Date:	Fri, 29 Apr 2011 19:47:14 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Joern Engel <joern@...fs.org>, Dave Chinner <dchinner@...hat.com>,
	Al Viro <viro@...iv.linux.org.uk>, werner <w.landgraf@...ru>
Cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: 2.6.39-rc5-git2 boot crashs

On Fri, Apr 29, 2011 at 7:31 PM, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> It looks like a NULL pointer dereference with offset 4, so at a guess,
> super->s_freeing_list.next is NULL, and it's the "next->prev = entry"
> instruction that faults when inserting into that list.
>
> How/why would s_freeing_list be NULL? I have no idea. But it looks
> like a failed mount, so presumably it was never initialized.

Hmm. super->s_freeing_list is initialized pretty late in
logfs_read_sb(), and any error path _before_ that point will result in
a "goto err1" in logfs_get_sb_device() which will do various iputs
etc. All without that list initialized. That would seem to be the
cause of this, possibly triggered by Al's changes to ->mount from
read_super.

Somebody who knows the code better than me (ie any reasonably
well-educated squirrel) should take another look, though.

Werner, if this is easily repeatable for you, could you test just
moving up the lines that initialize the superblock mutexes and the
s_freeing_list to the top of logfs_read_sb() rather than the end (ie
move the three lines that do

        mutex_init(&super->s_dirop_mutex);
        mutex_init(&super->s_object_alias_mutex);
        INIT_LIST_HEAD(&super->s_freeing_list);

to be before the call to mempool_create(). That way those things will
be initialized much earlier, which is definitely what we want.

Whether that's the only problem and actually fixes it, I won't even
begin to guess, though.

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