43 lines
1.6 KiB
Diff
43 lines
1.6 KiB
Diff
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
|
|
Origin: https://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git/commit?id=cd75e020ee28aa21985c6d8ebafc7457b4c51531
|
|
Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2018-10881
|
|
|
|
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>
|
|
---
|
|
fs/ext4/inline.c | 1 +
|
|
1 file changed, 1 insertion(+)
|
|
|
|
--- a/fs/ext4/inline.c
|
|
+++ b/fs/ext4/inline.c
|
|
@@ -437,6 +437,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) ||
|