https://bugzilla.kernel.org/show_bug.cgi?id=199977 --- Comment #4 from Theodore Tso (tytso@xxxxxxx) --- The original POC and your simplified POC bug are catching different problems. Part of the reason for this is that your fuzzed image has many different file system corruptions. So for example, inode #7 is completely corrupted in some strange way that causes e2fsck to not be able to fix file system at all. The kernel problems are triggered by it still trigger if you use debugfs to "clri <7>". This makes it harder for me to figure out what was the specific file system corruption that was causing the problem being reported in a specific bug. So with the simplified poc, I'm no longer seeing a problem with the tip of the ext4 branch because the simplified poc is only testing ext4's handling a specific corruption, and that's now fixed: [ 32.516640] EXT4-fs error (device loop0): ext4_xattr_ibody_find:2191: inode #14: comm poc-199997: corrupted in-inode xattr With your full POC, we're now tripping on the block 35 problem. I have a fix for it that I fixed for Bugzilla #200001, and I'm finding that one of the patches that I used to fix that problem also now fixes Bugzilla #19997, and it also fixes Bugzilla #199977 with your expanded poc.c: [ 26.736417] EXT4-fs error (device loop0): ext4_xattr_block_list:708: inode #15: comm poc-199977: corrupted xattr block 35 The specific problem here is that 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)". So now we get to an interesting philosophical question --- is the kernel bug fundamentally about the fuzzed image, or the poc.c code that was submitted to trigger the problem? And if you have a fuzzed image with many many corruptions, and a different poc.c is used to trigger kernel bug related to a different aspect of the image corruption, and with a completely different kernel signature, is it the same bug or a different bug? -- You are receiving this mail because: You are watching the assignee of the bug.
