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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:	Tue, 31 Jul 2012 18:34:02 -0400
From:	Theodore Ts'o <tytso@....edu>
To:	Eric Sandeen <sandeen@...hat.com>
Cc:	"Nelson, John R" <John_Nelson@...dent.uml.edu>,
	linux-ext4@...r.kernel.org
Subject: Re: Serious bug?

On Tue, Jul 31, 2012 at 04:40:36PM -0500, Eric Sandeen wrote:
> > The problem is that fallocate allocated a large number of blocks, which
> > mke2fs then immediately discarded as its first order of business.
> 
> Hm, then why didn't mkfs.ext4 -K solve the problem....

I wasn't able to replicate it with mkfs.ext4 -K on a 3.2 kernel.

However, with a 3.2 kernel, if you have a pre-existing file1 created
via the fallocate, mke2fs, umount, e2fsck series of commands, the
fallocate command will BUG.  More interestingly, if you have an extent
tree created using a 3.2 kernel, and then mount it on using a 3.5+ext4
patches for 3.6 kernel, it still BUG's.

It dies on line 837 of extent.c:

	len = EXT_LAST_INDEX(curp->p_hdr) - ix + 1;   
	BUG_ON(len < 0);

Obviously, it shouldn't do that, and that is a bug which is upstream
in the latest 3.6-rc0 kernel.  But it only happens on a file system
that had tripped over the 3.2 kernel bug first.  At the very least,
the BUG_ON should be an ext4_error() --- but given that this is a file
system that was given clean bill of health by e2fsck, we should handle
it in a more graceful way.

Of course, it might be a good idea if e2fsck was taught how to clean
up non-standard extent trees that have empty extent tree leaf nodes,
but nevertheless, the kernel *should* be able to handle
non-standard/non-optimal extent tree blocks in a sane fashion.

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