https://bugzilla.kernel.org/show_bug.cgi?id=200005 Theodore Tso (tytso@xxxxxxx) changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |tytso@xxxxxxx --- Comment #1 from Theodore Tso (tytso@xxxxxxx) --- Part of what is going on here is that there is an extended attribute for system.data stored in the inode in question, but the subsequent extended attribute is corrupted. The next problem is that the struct superblock has a required isize of 84, so this triggers an attempt to allocate an external xattr block to move some of the xattrs out. Then we try to allocate a block, and the block allocation bitmaps are corrupted, so the block allocation fails. Somewhere along this whole mess, we lose system.data extended attribute, which is why the subsequent write isn't able to find it, thus triggering the BUG_ON(is.s.not_found) So one or more of the various error handling isn't handling the errors=continue case correctly. Definitely a case of an extremely maliciously crafted file system! >From debugfs's stats command: Required extra isize: 84 Desired extra isize: 32 debugfs: stat <14> Inode: 14 Type: regular Mode: 0644 Flags: 0x10000000 Generation: 3064322158 Version: 0x00000000:00000001 User: 0 Group: 0 Project: 0 Size: 11 File ACL: 0 Links: 2 Blockcount: 0 Fragment: Address: 0 Number: 0 Size: 0 ctime: 0x5b189273:ba993a5c -- Wed Jun 6 22:03:31 2018 atime: 0x5b189273:b9a515a0 -- Wed Jun 6 22:03:31 2018 mtime: 0x5b189273:b9a515a0 -- Wed Jun 6 22:03:31 2018 crtime: 0x5b189273:b9a515a0 -- Wed Jun 6 22:03:31 2018 Size of extra inode fields: 32 debugfs: id -e <14> 0000 0000 02ea 0407 0000 0000 0000 0000 0000 ................ 0020 0000 0000 6461 7461 02e8 0300 0000 ffff ....data........ 0040 ff7f 0000 0000 0000 0000 0000 0000 0000 ................ 0060 0000 0000 0000 0000 0000 0000 0000 0000 ................ * 0120 0000 0000 0000 0000 0000 0000 0000 fffd ................ debugfs: id -b <14> 0000 6865 6c6c 6f20 776f 726c 6400 0000 0000 hello world..... 0020 0000 0000 0000 0000 0000 0000 0000 0000 ................ * -- You are receiving this mail because: You are watching the assignee of the bug.
