summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorAndreas Wellving <andreas.wellving@enea.com>2019-05-22 10:45:53 +0200
committerAdrian Mangeac <Adrian.Mangeac@enea.com>2019-05-22 12:24:18 +0200
commitb01da2a61cddb8c63483c478bea25083f34fbbcb (patch)
tree4d72f6c55128f5533201f2a7a5362fcc3f086641
parentea48a57d9cd08bd8619c8e1e7e281dd09fbbf2a2 (diff)
downloadenea-kernel-cache-b01da2a61cddb8c63483c478bea25083f34fbbcb.tar.gz
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 <andreas.wellving@enea.com>
-rw-r--r--patches/cve/CVE-2018-10881-ext4-clear-i_data-in-ext4_inode_info-when-removing-i.patch55
1 files changed, 55 insertions, 0 deletions
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 @@
1From deb465ec750b80776cc4ac5b92b72c0a71fd4f0b Mon Sep 17 00:00:00 2001
2From: Theodore Ts'o <tytso@mit.edu>
3Date: Fri, 15 Jun 2018 12:28:16 -0400
4Subject: [PATCH] ext4: clear i_data in ext4_inode_info when removing inline
5 data
6
7commit 6e8ab72a812396996035a37e5ca4b3b99b5d214b upstream.
8
9When converting from an inode from storing the data in-line to a data
10block, ext4_destroy_inline_data_nolock() was only clearing the on-disk
11copy of the i_blocks[] array. It was not clearing copy of the
12i_blocks[] in ext4_inode_info, in i_data[], which is the copy actually
13used by ext4_map_blocks().
14
15This didn't matter much if we are using extents, since the extents
16header would be invalid and thus the extents could would re-initialize
17the extents tree. But if we are using indirect blocks, the previous
18contents of the i_blocks array will be treated as block numbers, with
19potentially catastrophic results to the file system integrity and/or
20user data.
21
22This gets worse if the file system is using a 1k block size and
23s_first_data is zero, but even without this, the file system can get
24quite badly corrupted.
25
26This addresses CVE-2018-10881.
27
28https://bugzilla.kernel.org/show_bug.cgi?id=200015
29
30CVE: CVE-2018-10881
31Upstream-Status: Backport [https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-4.14.y&id=deb465ec750b80776cc4ac5b92b72c0a71fd4f0b]
32
33Signed-off-by: Theodore Ts'o <tytso@mit.edu>
34Cc: stable@kernel.org
35Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
36Signed-off-by: Andreas Wellving <andreas.wellving@enea.com>
37---
38 fs/ext4/inline.c | 1 +
39 1 file changed, 1 insertion(+)
40
41diff --git a/fs/ext4/inline.c b/fs/ext4/inline.c
42index 8f5dc243effd..afdef31ff728 100644
43--- a/fs/ext4/inline.c
44+++ b/fs/ext4/inline.c
45@@ -443,6 +443,7 @@ static int ext4_destroy_inline_data_nolock(handle_t *handle,
46
47 memset((void *)ext4_raw_inode(&is.iloc)->i_block,
48 0, EXT4_MIN_INLINE_DATA_SIZE);
49+ memset(ei->i_data, 0, EXT4_MIN_INLINE_DATA_SIZE);
50
51 if (ext4_has_feature_extents(inode->i_sb)) {
52 if (S_ISDIR(inode->i_mode) ||
53--
542.20.1
55