From: Theodore Ts'o Date: Fri, 15 Jun 2018 16:28:16 +0000 (-0400) Subject: ext4: clear i_data in ext4_inode_info when removing inline data X-Git-Tag: v4.1.12-124.31.3~218 X-Git-Url: https://www.infradead.org/git/?a=commitdiff_plain;h=59e53618868ba3a7518ab2c07860c9256daebcdc;p=users%2Fjedix%2Flinux-maple.git 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 Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman (cherry picked from commit deb465ec750b80776cc4ac5b92b72c0a71fd4f0b) Orabug: 29540709 CVE: CVE-2018-10881 Signed-off-by: John Donnelly Reviewed-by: Jack Vogel Signed-off-by: Brian Maly --- diff --git a/fs/ext4/inline.c b/fs/ext4/inline.c index f6fd830b2055..1b27b5743947 100644 --- a/fs/ext4/inline.c +++ b/fs/ext4/inline.c @@ -433,6 +433,7 @@ static int ext4_destroy_inline_data_nolock(handle_t *handle, memset((void *)ext4_raw_inode(&is.iloc)->i_block, 0, EXT4_MIN_INLINE_DATA_SIZE); + memset(ei->i_data, 0, EXT4_MIN_INLINE_DATA_SIZE); if (ext4_has_feature_extents(inode->i_sb)) { if (S_ISDIR(inode->i_mode) ||