From: Darrick J. Wong Date: Fri, 25 Jul 2014 12:41:11 +0000 (-0400) Subject: e2fsck: pass2 should not process directory blocks that are impossibly large X-Git-Tag: v1.42.12~68 X-Git-Url: https://git.whamcloud.com/gitweb?a=commitdiff_plain;h=c28c2741ba5af0fde93b50f992c525fea5b05cf6;p=tools%2Fe2fsprogs.git e2fsck: pass2 should not process directory blocks that are impossibly large Currently, directories cannot be fallocated, which means that the only way they get bigger is for the kernel to append blocks one by one. Therefore, if we encounter a logical block offset that is too big, we needn't bother adding it to the dblist for pass2 processing, because it's unlikely to contain a valid directory block. The code that handles extent based directories also does not add toobig blocks to the dblist. Note that we can easily cause e2fsck to fail with ENOMEM if we start feeding it really large logical block offsets, as the dblist implementation will try to realloc() an array big enough to hold it. Signed-off-by: Darrick J. Wong Signed-off-by: Theodore Ts'o --- diff --git a/e2fsck/pass1.c b/e2fsck/pass1.c index d056314..e05bf6f 100644 --- a/e2fsck/pass1.c +++ b/e2fsck/pass1.c @@ -2456,6 +2456,17 @@ static int process_block(ext2_filsys fs, blk = *block_nr = 0; ret_code = BLOCK_CHANGED; p->inode_modified = 1; + /* + * If the directory block is too big and is beyond the + * end of the FS, don't bother trying to add it for + * processing -- the kernel would never have created a + * directory this large, and we risk an ENOMEM abort. + * In any case, the toobig handler for extent-based + * directories also doesn't feed toobig blocks to + * pass 2. + */ + if (problem == PR_1_TOOBIG_DIR) + return ret_code; goto mark_dir; } else return 0; diff --git a/tests/f_hugedir_blocks/expect.1 b/tests/f_hugedir_blocks/expect.1 new file mode 100644 index 0000000..798a7ac --- /dev/null +++ b/tests/f_hugedir_blocks/expect.1 @@ -0,0 +1,10 @@ +Pass 1: Checking inodes, blocks, and sizes +Inode 12 is too big. Truncate? yes + +Block #1074791435 (13) causes directory to be too big. CLEARED. +Pass 2: Checking directory structure +Pass 3: Checking directory connectivity +Pass 4: Checking reference counts +Pass 5: Checking group summary information +test_filesys: 12/128 files (8.3% non-contiguous), 22/512 blocks +Exit status is 0 diff --git a/tests/f_hugedir_blocks/expect.2 b/tests/f_hugedir_blocks/expect.2 new file mode 100644 index 0000000..ac5f4c1 --- /dev/null +++ b/tests/f_hugedir_blocks/expect.2 @@ -0,0 +1,7 @@ +Pass 1: Checking inodes, blocks, and sizes +Pass 2: Checking directory structure +Pass 3: Checking directory connectivity +Pass 4: Checking reference counts +Pass 5: Checking group summary information +test_filesys: 12/128 files (8.3% non-contiguous), 22/512 blocks +Exit status is 0 diff --git a/tests/f_hugedir_blocks/image.gz b/tests/f_hugedir_blocks/image.gz new file mode 100644 index 0000000..1d54de8 Binary files /dev/null and b/tests/f_hugedir_blocks/image.gz differ diff --git a/tests/f_hugedir_blocks/name b/tests/f_hugedir_blocks/name new file mode 100644 index 0000000..d74761b --- /dev/null +++ b/tests/f_hugedir_blocks/name @@ -0,0 +1 @@ +crash e2fsck with a dir with an impossibly high logical blk offset