On Wed, Jun 17, 2009 at 02:32:18PM -0700, number9652 wrote: > I was too general in my statement above about what it broke. I think (didn't test) if a program follows this path: > extent_open(...,*handle) > write_inode_full(...,handle->inode,...) > that it will read uninitialized memory in write_inode_full. It >seems clear that all previously written code assumes that this path >is valid, and fixing all that to not assume that would seemingly be >much more than just what your patch fixes and require more time to >test. If you only use read/write_inode_full, everything is still >okay. Um, but that can't happen; the ext2_extent_handle_t type is an opaque type. So outside of code in lib/ext2fs/extent.c, no one else can see the inode in the ext2_handle_t. The safest thing to do is to simply make the extent code only use ext2_write_inode and ext2_read_inode. Otherwise, we have to worry about a user passing in the smaller 128-byte inode form. The extent code doesn't need any of the extended inode fields, so this is completely safe. - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
