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  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]
Date:	Wed, 12 Jun 2013 09:25:36 -0500
From:	Eric Sandeen <>
To:	"Theodore Ts'o" <>
CC:	Felipe Monteiro de Carvalho <>,
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.  :(


To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to
More majordomo info at

Powered by blists - more mailing lists