summaryrefslogtreecommitdiffstats
path: root/fs/exec.c
diff options
context:
space:
mode:
authorTheodore Ts'o <tytso@mit.edu>2018-06-15 12:28:16 -0400
committerTheodore Ts'o <tytso@mit.edu>2018-06-15 12:28:16 -0400
commit6e8ab72a812396996035a37e5ca4b3b99b5d214b (patch)
tree04bab287a2d0214e927d52914dcbb6d07fd723dc /fs/exec.c
parentbdbd6ce01a70f02e9373a584d0ae9538dcf0a121 (diff)
downloadlinux-6e8ab72a812396996035a37e5ca4b3b99b5d214b.tar.gz
linux-6e8ab72a812396996035a37e5ca4b3b99b5d214b.tar.bz2
linux-6e8ab72a812396996035a37e5ca4b3b99b5d214b.zip
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 Signed-off-by: Theodore Ts'o <tytso@mit.edu> Cc: stable@kernel.org
Diffstat (limited to 'fs/exec.c')
0 files changed, 0 insertions, 0 deletions