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: <20090423205124.GP3209@webber.adilger.int>
Date:	Thu, 23 Apr 2009 14:51:24 -0600
From:	Andreas Dilger <adilger@....com>
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 Apr 23, 2009  12:04 -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...)

There is a function ext2fs_extent_header_verify() that should be
catching the reported corruption.  The extents regression tests
that we have for e2fsck are detecting things like bad headers
in the tests that we have.

Using "debugfs" with "imap" to find and dump the inode blocks for
the corrupted inodes would be a good start for tracking this down.
If you have the space, saving an "e2image" of the filesystem should
also be done for future debugging.

Cheers, Andreas
--
Andreas Dilger
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.

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