linux-ext4 - Re: Serious bug?

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]

Message-ID: <20120731223402.GA3989@thunk.org>
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