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
| ||
|
Message-ID: <20130612125954.GB26388@thunk.org> Date: Wed, 12 Jun 2013 08:59:54 -0400 From: Theodore Ts'o <tytso@....edu> To: Felipe Monteiro de Carvalho <felipemonteiro.carvalho@...il.com> Cc: linux-ext4@...r.kernel.org Subject: Re: Too large value in inode.i_blocks[1] On Wed, Jun 12, 2013 at 05:08:21AM +0000, Felipe Monteiro de Carvalho wrote: > > Continuing in my adventures with ext4, now I am having > a problem that when reading the root > inode everything is fine. > When reading the inodes of directories placed on the file system root, > my reading fails, because inode.i_blocks has the following data > (for 1 particular subdir for example): > > 127754, > 4, > 0, > 0, > 1, > 1366, > 0,... > > The root works because in its inode i_blocks[1] has a smaller, > in-bounds value, but this one has > the first value completely out of bounds of the filesystem =( > > My ext4 filesystem has 3 incompat flags set: EXT4_FEATURE_INCOMPAT_FILETYPE, > EXT4_FEATURE_INCOMPAT_EXTENTS, EXT4_FEATURE_INCOMPAT_FLEX_BG The inode in question has the EXTENTS_FL flag set, which means the i_blocks[] array needs to get interpreted as the root node of the extent tree. 127754 is 0x0001F30A, where F30A is the magic number for the extents header, and 0x0001 means there is a single entry in the extent node. I **strongly** discourage people from trying to access the file system directly. It's much better to use the libext2fs library, since it will deal with these sorts of issues for you automatically. A program, even one written years ago, which uses the block iterator, or the directory iterator, or the namei function, or the ext2fs_file_{open,read,write,llseek}() functions provided by libext2fs, would have continued working when ext4 appeared, since we added ext4 support to the libext2fs library in such a way that older programs would continue working just fine. A good example of such a user of libext2fs is the e2tools userspace package. 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