linux-stable.git/fs/ext4, branch v4.16.7

ext4: fix bitmap position validation

2018-05-01T19:47:18+00:00

commit 22be37acce25d66ecf6403fc8f44df9c5ded2372 upstream.

Currently in ext4_valid_block_bitmap() we expect the bitmap to be
positioned anywhere between 0 and s_blocksize clusters, but that's
wrong because the bitmap can be placed anywhere in the block group. This
causes false positives when validating bitmaps on perfectly valid file
system layouts. Fix it by checking whether the bitmap is within the group
boundary.

The problem can be reproduced using the following

mkfs -t ext3 -E stride=256 /dev/vdb1
mount /dev/vdb1 /mnt/test
cd /mnt/test
wget https://cdn.kernel.org/pub/linux/kernel/v4.x/linux-4.16.3.tar.xz
tar xf linux-4.16.3.tar.xz

This will result in the warnings in the logs

EXT4-fs error (device vdb1): ext4_validate_block_bitmap:399: comm tar: bg 84: block 2774529: invalid block bitmap

[ Changed slightly for clarity and to not drop a overflow test -- TYT ]

Signed-off-by: Lukas Czerner 
Signed-off-by: Theodore Ts'o 
Reported-by: Ilya Dryomov 
Fixes: 7dac4a1726a9 ("ext4: add validity checks for bitmap block numbers")
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman

ext4: add validity checks for bitmap block numbers

2018-05-01T19:47:18+00:00

commit 7dac4a1726a9c64a517d595c40e95e2d0d135f6f upstream.

An privileged attacker can cause a crash by mounting a crafted ext4
image which triggers a out-of-bounds read in the function
ext4_valid_block_bitmap() in fs/ext4/balloc.c.

This issue has been assigned CVE-2018-1093.

BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=199181
BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1560782
Reported-by: Wen Xu 
Signed-off-by: Theodore Ts'o 
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman

ext4: add MODULE_SOFTDEP to ensure crc32c is included in the initramfs

2018-05-01T19:47:18+00:00

commit 7ef79ad52136712172eb0525bf0b462516bf2f93 upstream.

Fixes: a45403b51582 ("ext4: always initialize the crc32c checksum driver")
Reported-by: François Valenduc 
Signed-off-by: Theodore Ts'o 
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman

ext4: prevent right-shifting extents beyond EXT_MAX_BLOCKS

2018-05-01T19:47:17+00:00

commit 349fa7d6e1935f49bf4161c4900711b2989180a9 upstream.

During the "insert range" fallocate operation, extents starting at the
range offset are shifted "right" (to a higher file offset) by the range
length.  But, as shown by syzbot, it's not validated that this doesn't
cause extents to be shifted beyond EXT_MAX_BLOCKS.  In that case
->ee_block can wrap around, corrupting the extent tree.

Fix it by returning an error if the space between the end of the last
extent and EXT4_MAX_BLOCKS is smaller than the range being inserted.

This bug can be reproduced by running the following commands when the
current directory is on an ext4 filesystem with a 4k block size:

        fallocate -l 8192 file
        fallocate --keep-size -o 0xfffffffe000 -l 4096 -n file
        fallocate --insert-range -l 8192 file

Then after unmounting the filesystem, e2fsck reports corruption.

Reported-by: syzbot+06c885be0edcdaeab40c@syzkaller.appspotmail.com
Fixes: 331573febb6a ("ext4: Add support FALLOC_FL_INSERT_RANGE for fallocate")
Cc: stable@vger.kernel.org # v4.2+
Signed-off-by: Eric Biggers 
Signed-off-by: Theodore Ts'o 
Signed-off-by: Greg Kroah-Hartman

ext4: force revalidation of directory pointer after seekdir(2)

2018-04-24T07:42:59+00:00

commit e40ff213898502d299351cc2fe1e350cd186f0d3 upstream.

A malicious user could force the directory pointer to be in an invalid
spot by using seekdir(2).  Use the mechanism we already have to notice
if the directory has changed since the last time we called
ext4_readdir() to force a revalidation of the pointer.

Reported-by: syzbot+1236ce66f79263e8a862@syzkaller.appspotmail.com
Signed-off-by: Theodore Ts'o 
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman

ext4: add extra checks to ext4_xattr_block_get()

2018-04-24T07:42:59+00:00

commit 54dd0e0a1b255f115f8647fc6fb93273251b01b9 upstream.

Add explicit checks in ext4_xattr_block_get() just in case the
e_value_offs and e_value_size fields in the the xattr block are
corrupted in memory after the buffer_verified bit is set on the xattr
block.

Signed-off-by: Theodore Ts'o 
Cc: stable@kernel.org
Signed-off-by: Greg Kroah-Hartman

ext4: add bounds checking to ext4_xattr_find_entry()

2018-04-24T07:42:59+00:00

commit 9496005d6ca4cf8f5ee8f828165a8956872dc59d upstream.

Add some paranoia checks to make sure we don't stray beyond the end of
the valid memory region containing ext4 xattr entries while we are
scanning for a match.

Also rename the function to xattr_find_entry() since it is static and
thus only used in fs/ext4/xattr.c

Signed-off-by: Theodore Ts'o 
Cc: stable@kernel.org
Signed-off-by: Greg Kroah-Hartman

ext4: move call to ext4_error() into ext4_xattr_check_block()

2018-04-24T07:42:59+00:00

commit de05ca8526796c7e9f7c7282b7f89a818af19818 upstream.

Refactor the call to EXT4_ERROR_INODE() into ext4_xattr_check_block().
This simplifies the code, and fixes a problem where not all callers of
ext4_xattr_check_block() were not resulting in ext4_error() getting
called when the xattr block is corrupted.

Signed-off-by: Theodore Ts'o 
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman

ext4: don't allow r/w mounts if metadata blocks overlap the superblock

2018-04-24T07:42:59+00:00

commit 18db4b4e6fc31eda838dd1c1296d67dbcb3dc957 upstream.

If some metadata block, such as an allocation bitmap, overlaps the
superblock, it's very likely that if the file system is mounted
read/write, the results will not be pretty.  So disallow r/w mounts
for file systems corrupted in this particular way.

Signed-off-by: Theodore Ts'o 
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman

ext4: always initialize the crc32c checksum driver

2018-04-24T07:42:59+00:00

commit a45403b51582a87872927a3e0fc0a389c26867f1 upstream.

The extended attribute code now uses the crc32c checksum for hashing
purposes, so we should just always always initialize it.  We also want
to prevent NULL pointer dereferences if one of the metadata checksum
features is enabled after the file sytsem is originally mounted.

This issue has been assigned CVE-2018-1094.

https://bugzilla.kernel.org/show_bug.cgi?id=199183
https://bugzilla.redhat.com/show_bug.cgi?id=1560788

Signed-off-by: Theodore Ts'o 
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman