Issue metadata
Sign in to add a comment
|
CVE-2018-10881 CrOS: Vulnerability reported in Linux kernel |
||||||||||||||||||||||
Issue descriptionVOMIT (go/vomit) has received an external vulnerability report for the Linux kernel. Advisory: CVE-2018-10881 Details: http://vomit.googleplex.com/advisory?id=CVE/CVE-2018-10881 CVSS severity score: 4.9/10.0 Description: A flaw was found in the Linux kernel's ext4 filesystem. A local user can cause an out-of-bound access in ext4_get_group_info function, a denial of service, and a system crash by mounting and operating on a crafted ext4 filesystem image. This bug was filed by http://go/vomit Please contact us at vomit-team@google.com if you need any assistance.
,
Sep 24
,
Sep 25
,
Sep 25
,
Sep 26
,
Sep 28
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/f96622a5e9f2eae9703970aaf8be83b562f0e12b commit f96622a5e9f2eae9703970aaf8be83b562f0e12b Author: Theodore Ts'o <tytso@mit.edu> Date: Fri Sep 28 02:45:08 2018 UPSTREAM: 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 BUG= chromium:888319 TEST=None Change-Id: I0083260e7910ab23fb32934d30f6a11fc4e232c6 Signed-off-by: Theodore Ts'o <tytso@mit.edu> Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit deb465ec750b80776cc4ac5b92b72c0a71fd4f0b from linux-3.18.y) Signed-off-by: Zubin Mithra <zsm@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1240908 [modify] https://crrev.com/f96622a5e9f2eae9703970aaf8be83b562f0e12b/fs/ext4/inline.c
,
Sep 28
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/2e98414e6f0294268b61f5e7092c6903a93480f3 commit 2e98414e6f0294268b61f5e7092c6903a93480f3 Author: Theodore Ts'o <tytso@mit.edu> Date: Fri Sep 28 20:34:37 2018 UPSTREAM: ext4: clear i_data in ext4_inode_info when removing inline data 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 BUG= chromium:888319 TEST=None Change-Id: I0083260e7910ab23fb32934d30f6a11fc4e232c6 Signed-off-by: Theodore Ts'o <tytso@mit.edu> Cc: stable@kernel.org (cherry picked from commit 6e8ab72a812396996035a37e5ca4b3b99b5d214b) Signed-off-by: Zubin Mithra <zsm@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1251744 [modify] https://crrev.com/2e98414e6f0294268b61f5e7092c6903a93480f3/fs/ext4/inline.c
,
Oct 1
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/25bf955602e7e065b4108642f7df71e59c8c2388 commit 25bf955602e7e065b4108642f7df71e59c8c2388 Author: Theodore Ts'o <tytso@mit.edu> Date: Mon Oct 01 18:31:04 2018 UPSTREAM: ext4: clear i_data in ext4_inode_info when removing inline data 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 BUG= chromium:888319 TEST=None Change-Id: I0083260e7910ab23fb32934d30f6a11fc4e232c6 Signed-off-by: Theodore Ts'o <tytso@mit.edu> Cc: stable@kernel.org (cherry picked from commit 6e8ab72a812396996035a37e5ca4b3b99b5d214b) Signed-off-by: Zubin Mithra <zsm@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1251742 [modify] https://crrev.com/25bf955602e7e065b4108642f7df71e59c8c2388/fs/ext4/inline.c
,
Oct 1
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/1172ab4db387b2fcd9890a70fcd0460edf2c1554 commit 1172ab4db387b2fcd9890a70fcd0460edf2c1554 Author: Theodore Ts'o <tytso@mit.edu> Date: Mon Oct 01 18:31:07 2018 UPSTREAM: ext4: clear i_data in ext4_inode_info when removing inline data 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 BUG= chromium:888319 TEST=None Change-Id: I0083260e7910ab23fb32934d30f6a11fc4e232c6 Signed-off-by: Theodore Ts'o <tytso@mit.edu> Cc: stable@kernel.org (cherry picked from commit 6e8ab72a812396996035a37e5ca4b3b99b5d214b) Signed-off-by: Zubin Mithra <zsm@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1251743 [modify] https://crrev.com/1172ab4db387b2fcd9890a70fcd0460edf2c1554/fs/ext4/inline.c
,
Oct 1
,
Oct 2
,
Jan 8
This bug has been closed for more than 14 weeks. Removing security view restrictions. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by zsm@chromium.org
, Sep 24Labels: Security_Severity-Medium Security_Impact-Stable Pri-2
Owner: zsm@chromium.org
Status: Assigned (was: Untriaged)
Upstream commit is 6e8ab72a812("ext4: clear i_data in ext4_inode_info when removing inline data"). This commit is present in v4.14, v4.4. Older kernels do not have this commit. This commit is present in 3.18.y, will pull it into v3.18.