@@ -287,7 +287,7 @@ errcode_t ext2fs_flush2(ext2_filsys fs, int flags)
dgrp_t j;
#endif
char *group_ptr;
- int old_desc_blocks;
+ blk64_t old_desc_blocks;
struct ext2fs_numeric_progress_struct progress;
EXT2_CHECK_MAGIC(fs, EXT2_ET_MAGIC_EXT2FS_FILSYS);
@@ -346,7 +346,7 @@ errcode_t ext2fs_flush2(ext2_filsys fs, int flags)
group_ptr = (char *) group_shadow;
if (fs->super->s_feature_incompat & EXT2_FEATURE_INCOMPAT_META_BG) {
old_desc_blocks = fs->super->s_first_meta_bg;
- if (old_desc_blocks > fs->super->s_first_meta_bg)
+ if (old_desc_blocks > fs->desc_blocks)
old_desc_blocks = fs->desc_blocks;
} else
old_desc_blocks = fs->desc_blocks;
The bug fix in f66e6ce4446: "libext2fs: avoid buffer overflow if s_first_meta_bg is too big" had a typo in the fix for ext2fs_closefs(). In practice most of the security exposure was from the openfs path, since this meant if there was a carefully crafted file system, buffer overrun would be triggered when the file system was opened. However, if corrupted file system didn't trip over some corruption check, and then the file system was modified via tune2fs or debugfs, such that the superblock was marked dirty and then written out via the closefs() path, it's possible that the buffer overrun could be triggered when the file system is closed. Also clear up a signed vs unsigned warning while we're at it. Thanks to Nick Kralevich <nnk@google.com> for asking me to look at compiler warning in the code in question, which led me to notice the bug in f66e6ce4446. Addresses: CVE-2015-1572 Signed-off-by: Theodore Ts'o <tytso@mit.edu> --- lib/ext2fs/closefs.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)