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: <75A902DB-8A60-4CF5-982A-C32C5AB83C27@dilger.ca>
Date:	Sat, 15 Dec 2012 23:08:34 -0700
From:	Andreas Dilger <adilger@...ger.ca>
To:	Dâniel Fraga <fragabr@...il.com>
Cc:	"Theodore Ts'o" <tytso@....edu>,
	"linux-ext4@...r.kernel.org" <linux-ext4@...r.kernel.org>
Subject: Re: Kernel 3.7.0: bad header/extent

On 2012-12-15, at 22:39, Dâniel Fraga <fragabr@...il.com> wrote:

> On Sat, 15 Dec 2012 22:51:50 -0500
> Theodore Ts'o <tytso@....edu> wrote:
> 
>> Um, really?  **Exactly** the same error message?  That doesn't make
>> any sense.  The error message you quoted happens when the kernel
>> complains that the block numbers in the inode in question are invalid
>> (i.e., are too big for the inode in question, or point at file system
>> metadata).
> 
>    Yes. The exact same message before and after:
> 
> EXT4-fs error (device sda2): ext4_ext_check_inode:462: inode #9311628:
> comm less: bad header/extent: invalid extent entries - magic f30a,
> entries 1, max 4(4), depth 0(0)
> 
>> However, debugfs is not showing any extents --- which would be the
>> case after e2fsck repaired the file system (it would have zapped the
>> extent tree for the inode).
>> 
>> So (a) you did run e2fsck on an unmounted file system right?
> 
>    Yes, unmounted.
> 
>> (b) Can you send me the output of:
>> 
>>    debugfs -R "extents <9311628>" /dev/sda2
>> 
>> just to be sure we aren't missing anything.
> 
>    Here it is:
> 
> debugfs 1.41.12 (17-May-2010)
> Level Entries       Logical              Physical Length Flags
> 0/ 0   1/  1     0 - 4294967295  37333026 - 4332300321      0 

This is interesting. The one extent reports it is valid for 2^32-1 blocks, but this isn't possible with the current on-disk extent format. It looks like the extent is actually storing "-1" blocks (which is also invalid) but is incorrectly sign extended to 0xffffffff.

So e2fsck is allowing this, because it is theoretically possible, but the kernel can't actually use it.

Cheers, Andreas

>> Also, if you are using a really new kernel such as 3.6.x or 3.7.x, you
>> ***really*** shouldn't be using an ancient version of e2fsprogs such
>> as 1.41.12.  You really should be using e2fsprogs 1.42.x, preferably
>> the latest e2fsprogs 1.42.6.  I wonder if you are seeing a similar
>> message indicating that the file system had previously found an error,
>> and which wasn't cleared because you are using an ancient version of
>> e2fsprogs....
> 
>    Ok. The problem is that I'm trapped. I need to compile the most
> recent version (1.42.6) but the needed file to
> compile (/usr/include/dlfcn.h) isn't available (Input/output error)
> because of this problem. 
> 
>    But no problem, because I used e2fsck from "Recovery is
> possible 13.7" cd which uses e2fsck 1.42 version (so you can be sure I
> used e2fsck 1.42 version).
> 
>    Any more suggestions? Thanks!
> 
> -- 
> Linux 3.7.0: Terrified Chipmunk
> http://www.youtube.com/DanielFragaBR
> http://www.libertarios.org.br
> --
> 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
--
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