linux-stable.git/fs/ext3, branch linux-2.6.16.y

fix ext3 block bitmap leakage

2007-02-26T00:48:36+00:00

This patch fixes ext3 block bitmap leakage,
which leads to the following fsck messages on
_healthy_ filesystem:
Block bitmap differences:  -64159 -73707

All kernels up to 2.6.17 have this bug.

Found by
   Vasily Averin  and Andrey Savochkin 
Test case triggered the issue was created by
   Dmitry Monakhov 

Signed-Off-By: Kirill Korotaev 
Signed-off-by: Adrian Bunk

fix umask when noACL kernel meets extN tuned for ACLs

2007-02-13T12:10:20+00:00

Fix insecure default behaviour reported by Tigran Aivazian: if an
ext2 or ext3 filesystem is tuned to mount with "acl", but mounted by
a kernel built without ACL support, then umask was ignored when creating
inodes - though root or user has umask 022, touch creates files as 0666,
and mkdir creates directories as 0777.

This appears to have worked right until 2.6.11, when a fix to the default
mode on symlinks (always 0777) assumed VFS applies umask: which it does,
unless the mount is marked for ACLs; but ext[23] set MS_POSIXACL in
s_flags according to s_mount_opt set according to def_mount_opts.

We could revert to the 2.6.10 ext[23]_init_acl (adding an S_ISLNK test);
but other filesystems only set MS_POSIXACL when ACLs are configured.  We
could fix this at another level; but it seems most robust to avoid setting
the s_mount_opt flag in the first place (at the expense of more ifdefs).

Likewise don't set the XATTR_USER flag when built without XATTR support.

Signed-off-by: Hugh Dickins 
Signed-off-by: Adrian Bunk

handle ext3 directory corruption better (CVE-2006-6053)

2007-01-09T02:23:34+00:00

I've been using Steve Grubb's purely evil "fsfuzzer" tool, at
http://people.redhat.com/sgrubb/files/fsfuzzer-0.4.tar.gz

Basically it makes a filesystem, splats some random bits over it, then
tries to mount it and do some simple filesystem actions.

At best, the filesystem catches the corruption gracefully.  At worst,
things spin out of control.

As you might guess, we found a couple places in ext3 where things spin out
of control :)

First, we had a corrupted directory that was never checked for
consistency...  it was corrupt, and pointed to another bad "entry" of
length 0.  The for() loop looped forever, since the length of
ext3_next_entry(de) was 0, and we kept looking at the same pointer over and
over and over and over...  I modeled this check and subsequent action on
what is done for other directory types in ext3_readdir...

(adding this check adds some computational expense; I am testing a followup
patch to reduce the number of times we check and re-check these directory
entries, in all cases.  Thanks for the idea, Andreas).

Next we had a root directory inode which had a corrupted size, claimed to
be > 200M on a 4M filesystem.  There was only really 1 block in the
directory, but because the size was so large, readdir kept coming back for
more, spewing thousands of printk's along the way.

Per Andreas' suggestion, if we're in this read error condition and we're
trying to read an offset which is greater than i_blocks worth of bytes,
stop trying, and break out of the loop.

With these two changes fsfuzz test survives quite well on ext3.

Signed-off-by: Eric Sandeen 
Signed-off-by: Adrian Bunk

add forgotten ->b_data in memcpy() call in ext3/resize.c (oopsable)

2006-11-29T10:40:22+00:00

sbi->s_group_desc is an array of pointers to buffer_head.  memcpy() of
buffer size from address of buffer_head is a bad idea - it will generate
junk in any case, may oops if buffer_head is close to the end of slab
page and next page is not mapped and isn't what was intended there.
IOW, ->b_data is missing in that call.  Fortunately, result doesn't go
into the primary on-disk data structures, so only backup ones get crap
written to them; that had allowed this bug to remain unnoticed until
now.

Signed-off-by: Al Viro 
Signed-off-by: Adrian Bunk

ext3 -nobh option causes oops

2006-11-17T16:47:22+00:00

For files other than IFREG, nobh option doesn't make sense.  Modifications
to them are journalled and needs buffer heads to do that.  Without this
patch, we get kernel oops in page_buffers().

Signed-off-by: Badari Pulavarty 
Signed-off-by: Adrian Bunk

Have ext3 reject file handles with bad inode numbers early

2006-08-30T16:01:00+00:00

blatantly ripped off from Neil Brown's ext2 patch.

Signed-off-by: Eric Sandeen 
Acked-by: "Theodore Ts'o" 
Signed-off-by: Adrian Bunk

ext3: avoid triggering ext3_error on bad NFS file handle

2006-08-30T15:58:44+00:00

The inode number out of an NFS file handle gets passed eventually to
ext3_get_inode_block() without any checking.  If ext3_get_inode_block()
allows it to trigger an error, then bad filehandles can have unpleasant
effect - ext3_error() will usually cause a forced read-only remount, or a
panic if `errors=panic' was used.

So remove the call to ext3_error there and put a matching check in
ext3/namei.c where inode numbers are read off storage.

Andrew Morton fixed an off-by-one error.

Dann Frazier ported the patch to 2.6.16.

Signed-off-by: Neil Brown 
Signed-off-by: Adrian Bunk

[PATCH] ext3: Fix missed mutex unlock

2006-04-17T20:16:05+00:00

Missed unlock_super()call is added in error condition code path.

Signed-off-by: Leonid Ananiev 
Signed-off-by: Andrew Morton 
Signed-off-by: Greg Kroah-Hartman

[PATCH] ext3: fix nobh mode for chattr +j inodes

2006-03-11T17:19:34+00:00

One can do "chattr +j" on a file to change its journalling mode.  Fix
writeback mode with "nobh" handling for it.

Even though, we mount ext3 filesystem in writeback mode with "nobh" option,
some one can do "chattr +j" on a single file to force it to do journalled
mode.  In order to do journaling, ext3_block_truncate_page() need to
fallback to default case of creating buffers and adding them to transaction
etc.

Signed-off-by: Badari Pulavarty 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[PATCH] ext3: ext3_symlink should use GFP_NOFS allocations inside

2006-03-11T17:19:34+00:00

This patch fixes illegal __GFP_FS allocation inside ext3 transaction in
ext3_symlink().  Such allocation may re-enter ext3 code from
try_to_free_pages.  But JBD/ext3 code keeps a pointer to current journal
handle in task_struct and, hence, is not reentrable.

This bug led to "Assertion failure in journal_dirty_metadata()" messages.

http://bugzilla.openvz.org/show_bug.cgi?id=115

Signed-off-by: Andrey Savochkin 
Signed-off-by: Kirill Korotaev 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds