linux-stable.git/fs/ext4, branch linux-2.6.25.y

ext[234]: Avoid printk floods in the face of directory corruption (CVE-2008-3528)

2008-11-10T18:50:05+00:00

This is a trivial backport of the following upstream commits:

- bd39597cbd42a784105a04010100e27267481c67 (ext2)
- cdbf6dba28e8e6268c8420857696309470009fd9 (ext3)
- 9d9f177572d9e4eba0f2e18523b44f90dd51fe74 (ext4)

This addresses CVE-2008-3528

ext[234]: Avoid printk floods in the face of directory corruption

Note: some people thinks this represents a security bug, since it
might make the system go away while it is printing a large number of
console messages, especially if a serial console is involved.  Hence,
it has been assigned CVE-2008-3528, but it requires that the attacker
either has physical access to your machine to insert a USB disk with a
corrupted filesystem image (at which point why not just hit the power
button), or is otherwise able to convince the system administrator to
mount an arbitrary filesystem image (at which point why not just
include a setuid shell or world-writable hard disk device file or some
such).  Me, I think they're just being silly. --tytso

Signed-off-by: Eric Sandeen 
Signed-off-by: "Theodore Ts'o" 
Cc: linux-ext4@vger.kernel.org
Cc: Eugene Teo 
Signed-off-by: Greg Kroah-Hartman

ext3/4: fix uninitialized bs in ext3/4_xattr_set_handle()

2008-06-09T18:26:59+00:00

commit 7e01c8e5420b6c7f9d85d34c15d8c7a15c9fc720 upstream

This fix the uninitialized bs when we try to replace a xattr entry in
ibody with the new value which require more than free space.

This situation only happens we format ext3/4 with inode size more than 128 and
we have put xattr entries both in ibody and block.  The consequences about
this bug is we will lost the xattr block which pointed by i_file_acl with all
xattr entires in it.  We will alloc a new xattr block and put that large value
entry in it.  The old xattr block will become orphan block.

Signed-off-by: Tiger Yang 
Cc: 
Cc: Andreas Gruenbacher 
Acked-by: Andreas Dilger 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Chris Wright

vfs: fix possible deadlock in ext2, ext3, ext4 when using xattrs

2008-04-16T02:35:41+00:00

mb_cache_entry_alloc() was allocating cache entries with GFP_KERNEL.  But
filesystems are calling this function while holding xattr_sem so possible
recursion into the fs violates locking ordering of xattr_sem and transaction
start / i_mutex for ext2-4.  Change mb_cache_entry_alloc() so that filesystems
can specify desired gfp mask and use GFP_NOFS from all of them.

Signed-off-by: Jan Kara 
Reported-by: Dave Jones 
Cc: 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

ext4: add missing ext4_journal_stop()

2008-02-25T20:37:42+00:00

Add missing ext4_journal_stop() in error handling.

Signed-off-by: Akinobu Mita 
Signed-off-by: "Theodore Ts'o" 
Cc: Stephen Tweedie 
Cc: adilger@clusterfs.com
Cc: Andrew Morton 
Cc: Mingming Cao

ext4: ext4_find_next_zero_bit needs an aligned address on some arch

2008-02-23T06:38:34+00:00

ext4_find_next_zero_bit and ext4_find_next_bit needs a long aligned
address on x8_64. Add mb_find_next_zero_bit and mb_find_next_bit
and use them in the mballoc.

Fix: https://bugzilla.redhat.com/show_bug.cgi?id=433286

Eric Sandeen debugged the problem and suggested the fix.

Signed-off-by: Aneesh Kumar K.V 
Acked-by:      Eric Sandeen 
Signed-off-by: Mingming Cao 
Signed-off-by: "Theodore Ts'o"

ext4: set EXT4_EXTENTS_FL only for directory and regular files

2008-02-25T21:38:03+00:00

In addition, don't inherit EXT4_EXTENTS_FL from parent directory.
If we have a directory with extent flag set and later mount the file
system with -o noextents, the files created in that directory will also
have extent flag set but we would not have called ext4_ext_tree_init for
them. This will cause error later when we are verifying the extent header

Signed-off-by: Aneesh Kumar K.V 
Acked-off-by: Eric Sandeen 
Signed-off-by: Mingming Cao 
Signed-off-by: "Theodore Ts'o"

ext4: Don't mark filesystem error if fallocate fails

2008-02-25T20:41:35+00:00

If we fail to allocate blocks don't call ext4_error. Also don't hide
errors from ext4_get_blocks_wrap

Signed-off-by: Aneesh Kumar K.V 
Signed-off-by: "Theodore Ts'o"

ext4: Fix BUG when writing to an unitialized extent

2008-02-25T20:29:55+00:00

This patch fixes a bug when writing to preallocated but uninitialized
blocks, which resulted in a BUG in fs/buffer.c saying that the buffer
is not mapped.

When writing to a file, ext4_get_block_wrap() is called with create=1 in
order to request that blocks be allocated if necessary.  It currently
calls ext4_get_blocks() with create=0 in order to do a lookup first.  If
the inode contains an unitialized data block, the buffer head is left
unampped, which ext4_get_blocks_wrap() returns, causing the BUG.

We fix this by checking to see if the buffer head is unmapped, and if
so, we make sure the the buffer head is mapped by calling
ext4_ext_get_blocks with create=1.

Signed-off-by: Mingming Cao 
Signed-off-by: "Theodore Ts'o"

ext4: Don't use ext4_dec_count() if not needed

2008-02-15T20:00:38+00:00

The ext4_dec_count() function is only needed when dropping the i_nlink
count on inodes which are (or which could be) directories.  If we
*know* that the inode in question can't possibly be a directory, use
drop_nlink or clear_nlink() if we know i_nlink is 1.

Signed-off-by: "Theodore Ts'o"

ext4: modify block allocation algorithm for the last group

2008-02-15T18:43:07+00:00

When a directory inode is allocated in the last group and the last group
contains less than s_blocks_per_group blocks, the initial block allocated
for the directory is not always allocated in the same group as the
directory inode, but in one of the first groups of the filesystem (group 1
for example).
Depending on the current process's pid, ext4_find_near() and 
ext4_ext_find_goal() can return a block number greater than the maximum
blocks count in the filesystem and in that case the block will be not
allocated in the same group as the inode.

The following patch fixes the problem.

Should the modification also be done in ext2/3 code?

Signed-off-by: Valerie Clement 
Signed-off-by: Mingming Cao 
Signed-off-by: "Theodore Ts'o"