From b01da2a61cddb8c63483c478bea25083f34fbbcb Mon Sep 17 00:00:00 2001 From: Andreas Wellving Date: Wed, 22 May 2019 10:45:53 +0200 Subject: ext4: CVE-2018-10881 ext4: clear i_data in ext4_inode_info when removing inline data Reference: https://nvd.nist.gov/vuln/detail/CVE-2018-10881 https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-4.14.y&id=deb465ec750b80776cc4ac5b92b72c0a71fd4f0b Change-Id: I45dcf13bbc72e3ae398117481cc7899d4f58c960 Signed-off-by: Andreas Wellving --- ...i_data-in-ext4_inode_info-when-removing-i.patch | 55 ++++++++++++++++++++++ 1 file changed, 55 insertions(+) create mode 100644 patches/cve/CVE-2018-10881-ext4-clear-i_data-in-ext4_inode_info-when-removing-i.patch diff --git a/patches/cve/CVE-2018-10881-ext4-clear-i_data-in-ext4_inode_info-when-removing-i.patch b/patches/cve/CVE-2018-10881-ext4-clear-i_data-in-ext4_inode_info-when-removing-i.patch new file mode 100644 index 0000000..9cd1f86 --- /dev/null +++ b/patches/cve/CVE-2018-10881-ext4-clear-i_data-in-ext4_inode_info-when-removing-i.patch @@ -0,0 +1,55 @@ +From deb465ec750b80776cc4ac5b92b72c0a71fd4f0b Mon Sep 17 00:00:00 2001 +From: Theodore Ts'o +Date: Fri, 15 Jun 2018 12:28:16 -0400 +Subject: [PATCH] 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 + +CVE: CVE-2018-10881 +Upstream-Status: Backport [https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-4.14.y&id=deb465ec750b80776cc4ac5b92b72c0a71fd4f0b] + +Signed-off-by: Theodore Ts'o +Cc: stable@kernel.org +Signed-off-by: Greg Kroah-Hartman +Signed-off-by: Andreas Wellving +--- + fs/ext4/inline.c | 1 + + 1 file changed, 1 insertion(+) + +diff --git a/fs/ext4/inline.c b/fs/ext4/inline.c +index 8f5dc243effd..afdef31ff728 100644 +--- a/fs/ext4/inline.c ++++ b/fs/ext4/inline.c +@@ -443,6 +443,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) || +-- +2.20.1 + -- cgit v1.2.3-54-g00ecf