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:	Sun, 16 Dec 2012 09:50:13 -0500
From:	Theodore Ts'o <tytso@....edu>
To:	Andreas Dilger <adilger@...ger.ca>
Cc:	Dâniel Fraga <fragabr@...il.com>,
	"linux-ext4@...r.kernel.org" <linux-ext4@...r.kernel.org>
Subject: Re: Kernel 3.7.0: bad header/extent

On Sat, Dec 15, 2012 at 11:08:34PM -0700, Andreas Dilger wrote:
> > 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.

Actuually, the number of blocks in the extent was set to 0.  The
number reported by e2fsprogs contains is the inclusive range (i.e.,
lblk, lblk+len-1).

A fix for this was added to e2fsprogs in v1.42.2 in March 2012, by
commit 26c09eb8145a1 ("e2fsck: check for zero length extent").  There
was a regression which this commit would sometimes trigger which was
fixed in v1.42.4 (commit 9c40d14841f0, "e2fsck: only check for
zero-length leaf extents").  So e2fsck 1.42.4 or newer is recommended
to repair this sort of file system corruption.

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

What I would suggest that you do is to zap the bad inode and then run
e2fsck to repair the resulting damage:

debugfs -w -R "clri <9311628>" /dev/sda2
e2fsck -fy /dev/sda2

Then reinstall the glibc package (libc6-dev if you are using a
Debian-derived distribution), which supplies dlfcn.h, and then
recompile e2fsprogs so you can install a 1.42.x version of e2fsprogs.

I'm not entirely sure how the inode had gotten corrupted in the first
place, but I would be surprised if it was due to upgrading the kernel
from 3.6 to 3.7.  If you do see this corruption again, please let us
know, and hopefully we can try to figure out what the root cause of
the issue might be.

Regards,

						- 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

Powered by blists - more mailing lists