| From 6e8ab72a812396996035a37e5ca4b3b99b5d214b Mon Sep 17 00:00:00 2001 |
| From: Theodore Ts'o <tytso@mit.edu> |
| Date: Fri, 15 Jun 2018 12:28:16 -0400 |
| Subject: ext4: clear i_data in ext4_inode_info when removing inline data |
| |
| From: Theodore Ts'o <tytso@mit.edu> |
| |
| 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> |
| |
| --- |
| fs/ext4/inline.c | 1 + |
| 1 file changed, 1 insertion(+) |
| |
| --- a/fs/ext4/inline.c |
| +++ b/fs/ext4/inline.c |
| @@ -434,6 +434,7 @@ static int ext4_destroy_inline_data_nolo |
| |
| 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) || |
