linux-ext4 - Re: Too large value in inode.i

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: <51B884E0.5000405@redhat.com>
Date:	Wed, 12 Jun 2013 09:25:36 -0500
From:	Eric Sandeen <sandeen@...hat.com>
To:	"Theodore Ts'o" <tytso@....edu>
CC:	Felipe Monteiro de Carvalho <felipemonteiro.carvalho@...il.com>,
	linux-ext4@...r.kernel.org
Subject: Re: Too large value in inode.i_blocks[1]

On 6/12/13 8:52 AM, Theodore Ts'o wrote:
> On Wed, Jun 12, 2013 at 01:34:37PM +0000, Felipe Monteiro de Carvalho wrote:
>> I see that i_block has 15*4=60 bytes, and with EXTENTS_FL the first 12 bytes 
>> of i_block are filled with a ext4_extent_header
>>
>> What about the rest of it? I couldn't understand from the wiki page what
>> the rest holds exactly, it is not 100% clear ...
>>
>> My first guess would be that it has in this order:
>>
>> ext4_extent_header, 12 bytes long
>> ext4_extent_idx, 12 bytes long:
>> ext4_extent, 12 bytes long
>> ext4_extent_tail 4 bytes long
> 
> The ext4_extent_tail is not used in i_blocks[].  There will be up to 4
> ext4_extent structures, or ext4_extent_idx structures, depending on
> the depth of the tree.  The ext4_extent_idx structures are used for
> the interior inodes of the tree.  The ext4_extent structures are used
> for the leaf nodes of the tree.  The ext4_extent_tail is used in
> extent tree blocks so we can checksum the metadata if the
> metadata_csum feature is enabled.  The entire inode is checksummed, so
> we don't need the ext4_extent_tail in i_blocks[].
> 
>> Please don't worry that I am not frivolously attempting to access the
>> file system directly. My project explictly requires this, it is a
>> recovery tool to repair damaged file systems, and it must work in
>> Windows and Mac OS X. Maybe libext2fs works outside Linux, not sure, 
>> but anyway we already have source code for reading/recovering ext2/3, 
>> I am just expanding it to ext4. External dependencies are always
>> not ideal.
> 
> Libext2fs is designed to be cross OS portable.  It's used for the FUSE
> extensions that allow Mac and Windows machines to access ext2/3/4 file
> systems.  And libext2fs is designed to work with corrupted file
> systems, since after e2fsck is the normal tool most people use to
> repair damaged file systems, and debugfs is the command line tool
> which is used by people to examine file systems, corrupt fie systems
> for e2fsck test cases, and in a few cases, attempt to do manual repair
> of file systems in some extreme circumstances.

Indeed, I know of at least one "clean room" ext3 driver for windows
which did a fine job of corrupting proper ext3 filesystems, because it
was written incorrectly and didn't use the standard body of code.
Wasted a lot of my time getting to the bottom of that one.  :(

-Eric

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