https://bugzilla.kernel.org/show_bug.cgi?id=200001 --- Comment #2 from Theodore Tso (tytso@xxxxxxx) --- The fundamental problem block 35 is being used as a block allocation bitmap. On a number of your fuzzed images, one or more of the inodes use that same block as an external xattr block. So the problem is that block 35 is verified as an allocation bitmap; and then the buffer_verified flag is set. Then when we call ext4_xattr_check_block(), the code looks at the buffer_verified flag, and says, "Hurr durr.... this block has already been verified (as an allocation bitmap) so it must be OK; no need to verify it again (as an xattr block)". I have two patches to address this: ext4: add corruption check in ext4_xattr_set_entry() http://patchwork.ozlabs.org/patch/928666/ ext4: always verify the magic number in xattr blocks http://patchwork.ozlabs.org/patch/928667/ The first patch is sufficient to fix both this bug and #199997 by adding an sanity check in ext4_xattr_set_entry --- so that we're not dependent on verifying that xattr block is sane. However, there are a number of other places in fs/ext4/xattr.c where it's too hard to make sure extended attributes don't overrun the block boundaries without doing massive code restructuring. So the second patch fixes the problem where the block was marked as verified via as a different metadata block type and then trying to treat that block as an xattr block. -- You are receiving this mail because: You are watching the assignee of the bug.
