linux-ext4 - Re: ext4_ext_check_inode: bad header/extent in inode

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: <20090423204059.GM2723@mit.edu>
Date:	Thu, 23 Apr 2009 16:40:59 -0400
From:	Theodore Tso <tytso@....edu>
To:	Christian Kujau <lists@...dbynature.de>
Cc:	Eric Sandeen <sandeen@...hat.com>, linux-ext4@...r.kernel.org
Subject: Re: ext4_ext_check_inode: bad header/extent in inode

On Thu, Apr 23, 2009 at 12:04:38PM -0700, Christian Kujau wrote:
> On Thu, 23 Apr 2009, Eric Sandeen wrote:
> > I'd have expected fsck to find that, I think.  I'd first suggest using
> > 1.41.4 or 1.41.5 (probably released very soon) and see if that catches
> > it (I don't remember offhand if there is a relevant change since 1.41.3
> > but the check should be easy...)
> 
> Yes, in fact I _did_ have the latest e2fsprogs.git checkout [0] in 
> place, but did not use it. OK, compiled that, e2fsck still present itself 
> as "1.41.4" (which tree do I have to follow to get the 1.41.5 one?) but
> was not able to fix the errors either. Again, I do not expect e2fsck to 
> actuall fix it, because the damage I did to the fs was probably too 
> severe. But when fsck exits with code 0, I'd "expect" it to be clean. So, 
> I guess what I want is fsck to tell me to get my backups ready, as the fs 
> is damaged too heavily...

Hmm, it really should have detected it.  OK. if you still have the
filesystem around, can you first start by sending me an e2image file:

e2image /dev/md0 /tmp/md0.e2i

This is will dump out the superblock, block group descriptors, and
inode table, and it will allow me to take a look at the inodes in
question.

I tried corrupting the eh_magic field in a test filesystem, and e2fsck
caught it no problem.

Eventually I might need a raw e2image dump, i.e.:


	   e2image -r /dev/md0 - | bzip2 > /var/tmp/md0.e2i.bz2

but such things are very large, and reveal more information, since it
also includes directory names.  But let's see if a simple e2image file
is enough for me to get started.

Thanks,

					- 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