linux-ext4 - Re: Possible ext4 corruption

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1236735808.16191.23.camel@kulgan.wumi.org.au>
Date:	Wed, 11 Mar 2009 12:13:28 +1030
From:	Kevin Shanahan <kmshanah@...b.org.au>
To:	Andreas Dilger <adilger@....com>
Cc:	Theodore Tso <tytso@....edu>, Eric Sandeen <sandeen@...hat.com>,
	linux-ext4@...r.kernel.org
Subject: Re: Possible ext4 corruption - ACL related?

On Tue, 2009-03-10 at 18:38 -0600, Andreas Dilger wrote:
> On Mar 10, 2009  18:48 -0400, Theodore Ts'o wrote:
> > So now we know that the block containing inode 867 is 65+54 = 119
> 
> Or you can use imap (which Ted probably wrote in the first place. :-)
> 
> debugfs: imap some/problem/file
> Inode 867 is part of block group 0
> 	located at block 119, offset 0x0180
> 
> > Now to dump that block, we do:
> > 
> >     dd if=/dev/fs-device of=block-119.dump bs=4k skip=119 count=1
> 
> This part is the same.

Thanks guys.

It looks like there is still a problem there, even after fsck has done
it's cleanup.

Last night I got:

  getfattr: apps/Gestalt.Net/SetupCD/program\040files/Business\040Objects/Common/3.5/bin/RptControllers.dll: Input/output error

And syslog shows:

  Mar 11 00:06:01 hermes /USR/SBIN/CRON[26947]: (root) CMD (   /usr/local/bin/rsync-backup-all.sh)
  Mar 11 00:06:24 hermes kernel: attempt to access beyond end of device
  Mar 11 00:06:24 hermes kernel: dm-0: rw=0, want=946232834916360, limit=2147483648
  Mar 11 00:06:24 hermes kernel: attempt to access beyond end of device
  Mar 11 00:06:24 hermes kernel: dm-0: rw=0, want=946232834916360, limit=2147483648

hermes:~# getfattr /srv/samba/local/apps/Gestalt.Net/SetupCD/program\ files/Business\ Objects/Common/3.5/bin/RptControllers.dll 
getfattr: /srv/samba/local/apps/Gestalt.Net/SetupCD/program\040files/Business\040Objects/Common/3.5/bin/RptControllers.dll: Input/output error

hermes:~# debugfs /dev/dm-0
debugfs 1.41.3 (12-Oct-2008)
debugfs:  stat "local/apps/Gestalt.Net/SetupCD/program files/Business Objects/Common/3.5/bin/RptControllers.dll"

Inode: 875   Type: FIFO    Mode:  0611   Flags: 0xb3b9c185
Generation: 3690868    Version: 0x9d36b10d
User: 868313917   Group: -1340283792   Size: 0
File ACL: 0    Directory ACL: 0
Links: 1   Blockcount: 0
Fragment:  Address: 0    Number: 0    Size: 0
ctime: 0x0742afc4 -- Sun Nov 11 06:51:24 1973
atime: 0x472a2311 -- Fri Nov  2 05:33:45 2007
mtime: 0x80c59881 -- Fri Jun 18 09:51:21 2038
Size of extra inode fields: 4
BLOCKS:

debugfs:  imap "local/apps/Gestalt.Net/SetupCD/program files/Business Objects/Common/3.5/bin/RptControllers.dll"
Inode 875 is part of block group 0
	located at block 343, offset 0x0a00

hermes:~# dd if=/dev/dm-0 of=block-343.dump bs=4k skip=343 count=1
1+0 records in
1+0 records out
4096 bytes (4.1 kB) copied, 3.6316e-05 s, 113 MB/s

"strings block-343.dump" doesn't show anything obvious to me about where
the data came from, but I guess the concern would be whether fsck didn't
pick this up or maybe the corruption returned very quickly for some
reason.

Cheers,
Kevin.


Download attachment "block-343.dump" of type "application/octet-stream" (4096 bytes)