linux-ext4 - Re: ext3: ext4: Using uninitialized value

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: <20101016233513.GA31722@thunk.org>
Date:	Sat, 16 Oct 2010 19:35:13 -0400
From:	Ted Ts'o <tytso@....edu>
To:	Eric Sandeen <sandeen@...hat.com>
Cc:	Roman Borisov <ext-roman.borisov@...ia.com>,
	linux-ext4@...r.kernel.org, Jan Kara <jack@...e.cz>,
	Brad Spengler <spender@...ecurity.net>
Subject: Re: ext3: ext4: Using uninitialized value

On Wed, Oct 13, 2010 at 11:13:55AM -0500, Eric Sandeen wrote:
> On 10/13/2010 09:40 AM, Roman Borisov wrote:
> > Hello,
> > 
> > Could you clarify is there a bug in fs/ext4/namei.c,
> > ext4_dx_find_entry() and fs/ext4/namei.c, ext3_dx_find_entry()?

Let me guess, you compiled the kernel using Clang, right?  I recently
had a similar discussion with Brad about this issue.

> here we should find the . or .. (it's always going to be there, right?)

The problem is if '.' or '..' is not present, then when we call
ext3_htree_next_block(), it's not the fact that hash is uninitialized
which is the problem.  The bigger problem is that the frame structure
is not fully initialized; and we could end up dereference a NULL
pointer (on a 32-bit system) or a pointer filled with stack garbage
(on a 64-bit system).

Fortunately most of the time we'll never hit this case, since '.'  and
'..' handling is dealt with in fs/namei.c, and is never passed down to
the fs-specific layer.  The one exception to this is if the file
system is being used as an NFS file server, in which case it is
possible that the fs layer will be asked to look up "..".

So in the case where the directory is corrupted, and the file system
is being exported via NFS, it's possible that we could get a kernel
Oops.  Since we're only reading from the garbaged pointer, I'm pretty
sure this can't be leveraged into a security exposure, but still, it
would be good to fix this.

I have patches chained to this e-mail that should be applied for
ext3, and which I've queued for ext4.

						- 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