diff options
author | Theodore Ts'o <tytso@mit.edu> | 2018-06-15 12:28:16 -0400 |
---|---|---|
committer | Greg Kroah-Hartman <gregkh@linuxfoundation.org> | 2018-07-11 16:26:44 +0200 |
commit | a5e063d348bd2ef14fff96b129749409a8991ea5 (patch) | |
tree | b74db7a921ffac35f2d399eacf3b1d26f788ef35 /fs | |
parent | 2f135cc8c094152d361b3172d3f757369de28a08 (diff) |
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>
Diffstat (limited to 'fs')
-rw-r--r-- | fs/ext4/inline.c | 1 |
1 files changed, 1 insertions, 0 deletions
diff --git a/fs/ext4/inline.c b/fs/ext4/inline.c index 73cbc01ef5ad..e6ac24de119d 100644 --- a/fs/ext4/inline.c +++ b/fs/ext4/inline.c @@ -434,6 +434,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) || |