https://bugzilla.kernel.org/show_bug.cgi?id=199977 --- Comment #5 from Wen Xu (wen.xu@xxxxxxxxxx) --- (In reply to Theodore Tso from comment #4) > 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)". > I see, it seems to be a block type confusion :) > 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? Hmm, to me, a fs bug requires both fuzzed image and POC to trigger. They are all important. And I think it is better to use the root cause (the improper method to handle a particular field of a disk image appearing in the whole implementation) to differentiate bugs. The bugs of the same root cause but are triggered at different places because of different POCs should be treated as one bug. Otherwise, it is better to consider them as different ones. -- You are receiving this mail because: You are watching the assignee of the bug.
