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>

diff --git a/lib/ext2fs/inline_data.c b/lib/ext2fs/inline_data.c
index a9ec92377f2f7ca6f59767b2bc557cdf76525c48..f3cd3751f45ca66d4a0c466c59f4ec1e1313fa64 100644 (file)
--- a/lib/ext2fs/inline_data.c
+++ b/lib/ext2fs/inline_data.c
@@ -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;