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-next>] [day] [month] [year] [list]
Message-ID: <4FBFE0F9.8050509@redhat.com>
Date:	Fri, 25 May 2012 14:43:53 -0500
From:	Eric Sandeen <sandeen@...hat.com>
To:	ext4 development <linux-ext4@...r.kernel.org>
CC:	Lukáš Czerner <lczerner@...hat.com>
Subject: [PATCH] libext2fs: Fix rbtree backend for extent lengths greater
 than 2^32

Well, this took way too long to find, in retrospect.

In short, for a completely full filesystem with more than 2^32
blocks, the rbtree bitmap backend can assemble an extent of used
blocks which is longer than 2^32.  If it does, it will overflow
->count, and corrupt the rbtree for the bitmaps.

Discovered by completely filling a 32T filesystem using fallocate, and
then observing debugfs, dumpe2fs, and e2fsck all behaving badly.

(Note that filling with only 31 x 1T files did not show the problem,
because freespace was fragmented enough that there was no sufficiently
long range of used blocks.)

Signed-off-by: Eric Sandeen <sandeen@...hat.com>
---

An alternative solution might be to limit the rb_extent to
32-bit counts, and not merging beyond that.  For fragmented
freespace, as normal, perhaps that would be a better memory
savings?  But this fixes the immediate problem and seems worth
merging to avoid bad situations such as e2fsck corrupting a
perfectly good 32T filesystem...

diff --git a/lib/ext2fs/blkmap64_rb.c b/lib/ext2fs/blkmap64_rb.c
index 7ab72f4..a83f8ac 100644
--- a/lib/ext2fs/blkmap64_rb.c
+++ b/lib/ext2fs/blkmap64_rb.c
@@ -33,7 +33,7 @@
 struct bmap_rb_extent {
 	struct rb_node node;
 	__u64 start;
-	__u32 count;
+	__u64 count;
 };
 
 struct ext2fs_rb_private {

--
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