lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140718225446.31374.67903.stgit@birch.djwong.org>
Date:	Fri, 18 Jul 2014 15:54:46 -0700
From:	"Darrick J. Wong" <darrick.wong@...cle.com>
To:	tytso@....edu, darrick.wong@...cle.com
Cc:	linux-ext4@...r.kernel.org
Subject: [PATCH 20/24] 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 <darrick.wong@...cle.com>
---
 e2fsck/pass1.c                  |   11 +++++++++++
 tests/f_hugedir_blocks/expect.1 |   10 ++++++++++
 tests/f_hugedir_blocks/expect.2 |    7 +++++++
 tests/f_hugedir_blocks/image.gz |  Bin
 tests/f_hugedir_blocks/name     |    1 +
 5 files changed, 29 insertions(+)
 create mode 100644 tests/f_hugedir_blocks/expect.1
 create mode 100644 tests/f_hugedir_blocks/expect.2
 create mode 100644 tests/f_hugedir_blocks/image.gz
 create mode 100644 tests/f_hugedir_blocks/name


diff --git a/e2fsck/pass1.c b/e2fsck/pass1.c
index 7a16780..b478bca 100644
--- a/e2fsck/pass1.c
+++ b/e2fsck/pass1.c
@@ -2758,6 +2758,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 0000000000000000000000000000000000000000..1d54de806e596575a2a081931c587d77a695b79d
GIT binary patch
literal 2497
zcmb2|=3uxyeNiwI^V>Uy*}{P`3?Is;hhz(93W_gGC@...?s^bZx=}%o@...Sk`B?T
zq-@...MwNN_YU$ucr@$%0)-tMeNDSwEOM%u?w!>sn6uV%_P@...~X=|z4LVM?md6r
z7pbr$?9X~K*`y`8@...1;%l4vWs71L2A+AhcJ1}~$32`@...__5@...cu{$*XL{UA
zk#kR9cW6g;e)fOAU$1RucmBMXox5r>Yo7ixxV7ucn`2M2?>~>*yQlWq(VyGZkAM0e
z?c1F?`}W4*Wsj9#ey*`RHpiKtp+WJ)<@?Hpep^2O*O_wbW~L%{zyE7R1_p*3zoU+y
ze(3&EK8_#AdsFrE{r{^ImTV2U!yUkz8MRvU`v*B*;g@q;kG{FGw)J;;{<G6g6}FLH
z)2GSrDqsTYsP<U;{LlZ>DTV()`g>+*#sVpZbN?BE<n#X^HV_=xAajWoNE>`wCH?R}
zSPm@Cz>u)rY7IA(jZ7sdL`}9$1&Sm**}(*|hfHuF?9BSL*LQE6f9vl@...{NZ_ir=
z>S(rq^qZ^V_R>DL-s;%pXU&@...ITR7L;f?mNmyD{ddp*lgEB+kDWTN=u`X0_1~*c
z#5Eqwc=q#r&i+68yvDO%O-=4OY9a9W0pD}`!+-vif8PIQ`=9sWzdsjdC(V9+{`iHf
z<@e?O`u>~lzVC0I9tW8YAJsM*0;3@...mvsFd71*AwVbu4qW@...8xHe+C8x1^`B?
B32*=a

literal 0
HcmV?d00001

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

--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ