vitalif
/
e2fsprogs
mirror of https://github.com/vitalif/e2fsprogs
1
0
Fork 0
Code Issues Releases Wiki Activity

libext2fs: during inlinedata expand, don't corrupt inode 

When expanding an inline data inode, it's possible that the reduction
in the size of the EA structures causes the freeing of the EA block,
which changes the inode.  If this happens, the local version of the
inode that ext2fs_inline_data_expand was modifying will be out of sync
with what's on the disk.  This local copy gets written out to disk
after a block allocation, at which point it's possible that the inode
EA block and logical block zero point to the same physical block,
which is bad news.

Therefore, write the local copy to disk before removing the inline
data EA, and reread it afterwards.

Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
crypto
Darrick J. Wong 2014-03-14 09:28:13 -04:00 committed by Theodore Ts'o
parent cc7d12ac37
commit 179e3bd708
1 changed files with 13 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

13
lib/ext2fs/inline_data.c
View File

@ -460,7 +460,20 @@ errcode_t ext2fs_inline_data_expand(ext2_filsys fs, ext2_ino_t ino)
}
memset((void *)inode.i_block, 0, EXT4_MIN_INLINE_DATA_SIZE);
/*
* NOTE: We must do this write -> ea_remove -> read cycle here because
* removing the inline data EA can free the EA block, which is a change
* that our stack copy of the inode will never see. If that happens,
* we can end up with the EA block and lblk 0 pointing to the same
* pblk, which is bad news.
*/
retval = ext2fs_write_inode(fs, ino, &inode);
if (retval)
goto errout;
retval = ext2fs_inline_data_ea_remove(fs, ino);
if (retval)
goto errout;
retval = ext2fs_read_inode(fs, ino, &inode);
if (retval)
goto errout;