]> www.infradead.org Git - users/jedix/linux-maple.git/commit
ext4: clear i_data in ext4_inode_info when removing inline data
authorTheodore Ts'o <tytso@mit.edu>
Fri, 15 Jun 2018 16:28:16 +0000 (12:28 -0400)
committerBrian Maly <brian.maly@oracle.com>
Wed, 27 Mar 2019 18:56:42 +0000 (14:56 -0400)
commit59e53618868ba3a7518ab2c07860c9256daebcdc
treee4e67f7ce9d67d2cf3d22e5ec48591ad063e88b4
parent8313adc6c44f95f67591e8fab33a4a75bb8fc683
ext4: clear i_data in ext4_inode_info when removing inline data

commit 6e8ab72a812396996035a37e5ca4b3b99b5d214b upstream.

When converting from an inode from storing the data in-line to a data
block, ext4_destroy_inline_data_nolock() was only clearing the on-disk
copy of the i_blocks[] array.  It was not clearing copy of the
i_blocks[] in ext4_inode_info, in i_data[], which is the copy actually
used by ext4_map_blocks().

This didn't matter much if we are using extents, since the extents
header would be invalid and thus the extents could would re-initialize
the extents tree.  But if we are using indirect blocks, the previous
contents of the i_blocks array will be treated as block numbers, with
potentially catastrophic results to the file system integrity and/or
user data.

This gets worse if the file system is using a 1k block size and
s_first_data is zero, but even without this, the file system can get
quite badly corrupted.

This addresses CVE-2018-10881.

https://bugzilla.kernel.org/show_bug.cgi?id=200015

Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Cc: stable@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit deb465ec750b80776cc4ac5b92b72c0a71fd4f0b)

Orabug: 29540709
CVE: CVE-2018-10881

Signed-off-by: John Donnelly <John.P.Donnelly@oracle.com>
Reviewed-by: Jack Vogel <jack.vogel@oracle.com>
Signed-off-by: Brian Maly <brian.maly@oracle.com>
fs/ext4/inline.c