CVE-2021-47406

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: add error checking to ext4_ext_replay_set_iblocks()<br /> <br /> If the call to ext4_map_blocks() fails due to an corrupted file<br /> system, ext4_ext_replay_set_iblocks() can get stuck in an infinite<br /> loop. This could be reproduced by running generic/526 with a file<br /> system that has inline_data and fast_commit enabled. The system will<br /> repeatedly log to the console:<br /> <br /> EXT4-fs warning (device dm-3): ext4_block_to_path:105: block 1074800922 &gt; max in inode 131076<br /> <br /> and the stack that it gets stuck in is:<br /> <br /> ext4_block_to_path+0xe3/0x130<br /> ext4_ind_map_blocks+0x93/0x690<br /> ext4_map_blocks+0x100/0x660<br /> skip_hole+0x47/0x70<br /> ext4_ext_replay_set_iblocks+0x223/0x440<br /> ext4_fc_replay_inode+0x29e/0x3b0<br /> ext4_fc_replay+0x278/0x550<br /> do_one_pass+0x646/0xc10<br /> jbd2_journal_recover+0x14a/0x270<br /> jbd2_journal_load+0xc4/0x150<br /> ext4_load_journal+0x1f3/0x490<br /> ext4_fill_super+0x22d4/0x2c00<br /> <br /> With this patch, generic/526 still fails, but system is no longer<br /> locking up in a tight loop. It&amp;#39;s likely the root casue is that<br /> fast_commit replay is corrupting file systems with inline_data, and we<br /> probably need to add better error handling in the fast commit replay<br /> code path beyond what is done here, which essentially just breaks the<br /> infinite loop without reporting the to the higher levels of the code.