From: Ted Ts'o <tytso@mit.edu>
To: Eric Sandeen <sandeen@redhat.com>
Cc: Roman Borisov <ext-roman.borisov@nokia.com>,
linux-ext4@vger.kernel.org, Jan Kara <jack@suse.cz>,
Brad Spengler <spender@grsecurity.net>
Subject: Re: ext3: ext4: Using uninitialized value
Date: Sat, 16 Oct 2010 19:35:13 -0400 [thread overview]
Message-ID: <20101016233513.GA31722@thunk.org> (raw)
In-Reply-To: <4CB5DAC3.3040605@redhat.com>
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
next prev parent reply other threads:[~2010-10-16 23:35 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-10-13 14:40 ext3: ext4: Using uninitialized value Roman Borisov
2010-10-13 16:13 ` Eric Sandeen
2010-10-13 18:56 ` Andreas Dilger
2010-10-14 10:10 ` Roman Borisov
2010-10-14 13:42 ` Eric Sandeen
2010-10-16 23:35 ` Ted Ts'o [this message]
2010-10-16 23:36 ` [PATCH 1/2] ext3: Avoid uninitialized memory references with a corrupted htree directory Theodore Ts'o
2010-10-18 10:05 ` Jan Kara
2010-10-19 7:12 ` Andreas Dilger
2010-10-16 23:37 ` [PATCH 2/2] ext3: Use search_dirblock() in ext3_dx_find_entry() Theodore Ts'o
2010-10-16 23:37 ` [PATCH 1/2] ext4: Avoid uninitialized memory references in ext3_htree_next_block() Theodore Ts'o
2010-10-18 4:27 ` Andreas Dilger
2010-10-16 23:37 ` [PATCH 2/2] ext4: Use search_dirblock() in ext4_dx_find_entry() Theodore Ts'o
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20101016233513.GA31722@thunk.org \
--to=tytso@mit.edu \
--cc=ext-roman.borisov@nokia.com \
--cc=jack@suse.cz \
--cc=linux-ext4@vger.kernel.org \
--cc=sandeen@redhat.com \
--cc=spender@grsecurity.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).