linux-ext4 - Re: Kernel 3.7.0: bad header/extent

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]

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