lkml.org 
[lkml]   [2018]   [Jul]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    Patch in this message
    /
    From
    Subject[PATCH 4.9 32/52] ext4: clear i_data in ext4_inode_info when removing inline data
    Date
    4.9-stable review patch.  If anyone has any objections, please let me know.

    ------------------

    From: Theodore Ts'o <tytso@mit.edu>

    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

    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Cc: stable@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

    ---
    fs/ext4/inline.c | 1 +
    1 file changed, 1 insertion(+)

    --- a/fs/ext4/inline.c
    +++ b/fs/ext4/inline.c
    @@ -434,6 +434,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) ||

    \
     
     \ /
      Last update: 2018-07-10 20:32    [W:4.188 / U:0.140 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site