linux-ext4 - Re: ext4 bug and/or e2fsck hole

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: <20090407235140.GH3204@webber.adilger.int>
Date:	Tue, 07 Apr 2009 16:51:40 -0700
From:	Andreas Dilger <adilger@....com>
To:	Kevin Shanahan <kmshanah@...b.org.au>
Cc:	linux-ext4@...r.kernel.org
Subject: Re: ext4 bug and/or e2fsck hole

On Apr 08, 2009  09:09 +0930, Kevin Shanahan wrote:
> On Tue, Apr 07, 2009 at 04:13:24PM -0700, Andreas Dilger wrote:
> > What version of e2fsprogs is this?  It definitely appears that the
> > inode is corrupted (bad i_file_acl field), and e2fsck isn't fixing it.
> 
> Using current Debian stable release:
> 
> hermes:~# e2fsck -V
> e2fsck 1.41.3 (12-Oct-2008)
>         Using EXT2FS Library version 1.41.3, 12-Oct-2008
> 
> > Can you please dump this inode using "debugfs -c -R 'imap 383' /dev/dm-0"
> > and "dd if=/dev/dm-0 of=/tmp/bad_inode.383.bin bs=4k count=1 skip={blocknr}".
> 
> hermes:~# debugfs -c -R 'imap 383' /dev/dm-0
> debugfs 1.41.3 (12-Oct-2008)
> /dev/dm-0: catastrophic mode - not reading inode or group bitmaps
> 383: File not found by ext2_lookup 
> hermes:~# debugfs -c -R 'imap <383>' /dev/dm-0
> debugfs 1.41.3 (12-Oct-2008)
> /dev/dm-0: catastrophic mode - not reading inode or group bitmaps
> Inode 383 is part of block group 0
>         located at block 312, offset 0x0e00

000e00 845ac901 00000000 5d648154 9f6a0b23
000e10 22344c51 00000000 0001e064 00000000
000e20 c4a8c000 c591d204 9105f87d c6cf35c8
000e30 82016f23 d3a7defb af4ab245 d3123ef4
000e40 87cd5ebe fa60d394 db745504 a6f3a34d
000e50 6a5985d4 ac8cebf1 a605db29 548c8e6e
000e60 f665b0c8 e58c1934 00000000 00000000
000e70 00000000 5db50000 b6ae09f5 6bc9469f
000e80 9c950004 5b8f755b e31b8760 e49bfe80
000e90 215242b0 f708f501 ab1d808d 4143a941
000ea0 83ff4c83 36858a3e db376e67 c87ee64e
000eb0 c10e0487 8dc325a1 4e7327aa 71a6c841
000ec0 4014140b d18816c7 87898dba b986e891
000ed0 2dab53ed 8fef04ef f33deb1c 47010862
000ee0 c551c546 2c463176 0b0c554a 76af3850
000ef0 271cc4fa 457664de 79b808d5 4456415a

This inode looks like total garbage, unlike the ones immediately before
and after it in the same block.  Why e2fsck doesn't complain about this
inode is a bit of a mystery.


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