linux-stable.git/fs/ext4, branch v3.4.106

ext4: bail out from make_indexed_dir() on first error

2015-02-02T09:05:09+00:00

commit 6050d47adcadbb53582434d919ed7f038d936712 upstream.

When ext4_handle_dirty_dx_node() or ext4_handle_dirty_dirent_node()
fail, there's really something wrong with the fs and there's no point in
continuing further. Just return error from make_indexed_dir() in that
case. Also initialize frames array so that if we return early due to
error, dx_release() doesn't try to dereference uninitialized memory
(which could happen also due to error in do_split()).

Coverity-id: 741300
Signed-off-by: Jan Kara 
Signed-off-by: Theodore Ts'o 
[lizf: Backported to 3.4:
 - adjust context
 - replace ext4_handle_dirty_{dx,dirent}_node() with
   ext4_handle_dirty_metadata()]
Signed-off-by: Zefan Li

ext4: fix oops when loading block bitmap failed

2015-02-02T09:05:08+00:00

commit 599a9b77ab289d85c2d5c8607624efbe1f552b0f upstream.

When we fail to load block bitmap in __ext4_new_inode() we will
dereference NULL pointer in ext4_journal_get_write_access(). So check
for error from ext4_read_block_bitmap().

Coverity-id: 989065
Signed-off-by: Jan Kara 
Signed-off-by: Theodore Ts'o 
Signed-off-by: Zefan Li

ext4: fix overflow when updating superblock backups after resize

2015-02-02T09:05:08+00:00

commit 9378c6768e4fca48971e7b6a9075bc006eda981d upstream.

When there are no meta block groups update_backups() will compute the
backup block in 32-bit arithmetics thus possibly overflowing the block
number and corrupting the filesystem. OTOH filesystems without meta
block groups larger than 16 TB should be rare. Fix the problem by doing
the counting in 64-bit arithmetics.

Coverity-id: 741252
Signed-off-by: Jan Kara 
Signed-off-by: Theodore Ts'o 
Reviewed-by: Lukas Czerner 
[lizf: Backported to 3.4: adjust context]
Signed-off-by: Zefan Li

ext4: fix reservation overflow in ext4_da_write_begin

2015-02-02T09:04:53+00:00

commit 0ff8947fc5f700172b37cbca811a38eb9cb81e08 upstream.

Delalloc write journal reservations only reserve 1 credit,
to update the inode if necessary.  However, it may happen
once in a filesystem's lifetime that a file will cross
the 2G threshold, and require the LARGE_FILE feature to
be set in the superblock as well, if it was not set already.

This overruns the transaction reservation, and can be
demonstrated simply on any ext4 filesystem without the LARGE_FILE
feature already set:

dd if=/dev/zero of=testfile bs=1 seek=2147483646 count=1 \
	conv=notrunc of=testfile
sync
dd if=/dev/zero of=testfile bs=1 seek=2147483647 count=1 \
	conv=notrunc of=testfile

leads to:

EXT4-fs: ext4_do_update_inode:4296: aborting transaction: error 28 in __ext4_handle_dirty_super
EXT4-fs error (device loop0) in ext4_do_update_inode:4301: error 28
EXT4-fs error (device loop0) in ext4_reserve_inode_write:4757: Readonly filesystem
EXT4-fs error (device loop0) in ext4_dirty_inode:4876: error 28
EXT4-fs error (device loop0) in ext4_da_write_end:2685: error 28

Adjust the number of credits based on whether the flag is
already set, and whether the current write may extend past the
LARGE_FILE limit.

Signed-off-by: Eric Sandeen 
Signed-off-by: Theodore Ts'o 
Reviewed-by: Andreas Dilger 
[lizf: Backported to 3.4:
 - adjust context
 - ext4_journal_start() has no parameter type]
Signed-off-by: Zefan Li

ext4: add ext4_iget_normal() which is to be used for dir tree lookups

2015-02-02T09:04:53+00:00

commit f4bb2981024fc91b23b4d09a8817c415396dbabb upstream.

If there is a corrupted file system which has directory entries that
point at reserved, metadata inodes, prohibit them from being used by
treating them the same way we treat Boot Loader inodes --- that is,
mark them to be bad inodes.  This prohibits them from being opened,
deleted, or modified via chmod, chown, utimes, etc.

In particular, this prevents a corrupted file system which has a
directory entry which points at the journal inode from being deleted
and its blocks released, after which point Much Hilarity Ensues.

Reported-by: Sami Liedes 
Signed-off-by: Theodore Ts'o 
Signed-off-by: Zefan Li

ext4: don't orphan or truncate the boot loader inode

2015-02-02T09:04:52+00:00

commit e2bfb088fac03c0f621886a04cffc7faa2b49b1d upstream.

The boot loader inode (inode #5) should never be visible in the
directory hierarchy, but it's possible if the file system is corrupted
that there will be a directory entry that points at inode #5.  In
order to avoid accidentally trashing it, when such a directory inode
is opened, the inode will be marked as a bad inode, so that it's not
possible to modify (or read) the inode from userspace.

Unfortunately, when we unlink this (invalid/illegal) directory entry,
we will put the bad inode on the ophan list, and then when try to
unlink the directory, we don't actually remove the bad inode from the
orphan list before freeing in-memory inode structure.  This means the
in-memory orphan list is corrupted, leading to a kernel oops.

In addition, avoid truncating a bad inode in ext4_destroy_inode(),
since truncating the boot loader inode is not a smart thing to do.

Reported-by: Sami Liedes 
Reviewed-by: Jan Kara 
Signed-off-by: Theodore Ts'o 
[lizf: Backported to 3.4: adjust context]
Signed-off-by: Zefan Li

ext4: don't check quota format when there are no quota files

2015-02-02T09:04:51+00:00

commit 279bf6d390933d5353ab298fcc306c391a961469 upstream.

The check whether quota format is set even though there are no
quota files with journalled quota is pointless and it actually
makes it impossible to turn off journalled quotas (as there's
no way to unset journalled quota format). Just remove the check.

Signed-off-by: Jan Kara 
Signed-off-by: Theodore Ts'o 
Signed-off-by: Zefan Li

ext4: check EA value offset when loading

2015-02-02T09:04:51+00:00

commit a0626e75954078cfacddb00a4545dde821170bc5 upstream.

When loading extended attributes, check each entry's value offset to
make sure it doesn't collide with the entries.

Without this check it is easy to crash the kernel by mounting a
malicious FS containing a file with an EA wherein e_value_offs = 0 and
e_value_size > 0 and then deleting the EA, which corrupts the name
list.

(See the f_ea_value_crash test's FS image in e2fsprogs for an example.)

Signed-off-by: Darrick J. Wong 
Signed-off-by: Theodore Ts'o 
[lizf: Backported to 3.4: adjust context]
Signed-off-by: Zefan Li

ext4: avoid trying to kfree an ERR_PTR pointer

2014-12-01T10:02:41+00:00

commit a9cfcd63e8d206ce4235c355d857c4fbdf0f4587 upstream.

Thanks to Dan Carpenter for extending smatch to find bugs like this.
(This was found using a development version of smatch.)

Fixes: 36de928641ee48b2078d3fe9514242aaa2f92013
Reported-by: Dan Carpenter 
[lizf: Backported to 3.4:
- s/new.bh/new_bh/
- drop the change to ext4_cross_rename()]
Signed-off-by: Zefan Li

ext4: propagate errors up to ext4_find_entry()'s callers

2014-12-01T10:02:41+00:00

commit 36de928641ee48b2078d3fe9514242aaa2f92013 upstream.

If we run into some kind of error, such as ENOMEM, while calling
ext4_getblk() or ext4_dx_find_entry(), we need to make sure this error
gets propagated up to ext4_find_entry() and then to its callers.  This
way, transient errors such as ENOMEM can get propagated to the VFS.
This is important so that the system calls return the appropriate
error, and also so that in the case of ext4_lookup(), we return an
error instead of a NULL inode, since that will result in a negative
dentry cache entry that will stick around long past the OOM condition
which caused a transient ENOMEM error.

Google-Bug-Id: #17142205

Signed-off-by: Theodore Ts'o 
[lizf: Backported to 3.4:
- adjust context
- s/old.bh/old_bh/g
- s/new.bh/new_bh/g
- drop the changes to ext4_find_delete_entry() and ext4_cross_rename()
- add return value check for one more exr4_find_entry() in ext4_rename()]
Signed-off-by: Zefan Li