In the Linux kernel, the following vulnerability has been resolved:
ext4: fix bug on in ext4escacheextent as ext4splitextentat failed
We got follow bugon when run fsstress with injecting IO fault: [130747.323114] kernel BUG at fs/ext4/extentsstatus.c:762! [130747.323117] Internal error: Oops - BUG: 0 [#1] SMP ...... [130747.334329] Call trace: [130747.334553] ext4escacheextent+0x150/0x168 [ext4] [130747.334975] ext4cacheextents+0x64/0xe8 [ext4] [130747.335368] ext4findextent+0x300/0x330 [ext4] [130747.335759] ext4extmapblocks+0x74/0x1178 [ext4] [130747.336179] ext4mapblocks+0x2f4/0x5f0 [ext4] [130747.336567] ext4mpagereadpages+0x4a8/0x7a8 [ext4] [130747.336995] ext4readpage+0x54/0x100 [ext4] [130747.337359] genericfilebufferedread+0x410/0xae8 [130747.337767] genericfilereaditer+0x114/0x190 [130747.338152] ext4filereaditer+0x5c/0x140 [ext4] [130747.338556] _vfsread+0x11c/0x188 [130747.338851] vfsread+0x94/0x150 [130747.339110] ksysread+0x74/0xf0
This patch's modification is according to Jan Kara's suggestion in: https://patchwork.ozlabs.org/project/linux-ext4/patch/20210428085158.3728201-1-yebin10@huawei.com/ "I see. Now I understand your patch. Honestly, seeing how fragile is trying to fix extent tree after split has failed in the middle, I would probably go even further and make sure we fix the tree properly in case of ENOSPC and EDQUOT (those are easily user triggerable). Anything else indicates a HW problem or fs corruption so I'd rather leave the extent tree as is and don't try to fix it (which also means we will not create overlapping extents)."