CVE-2022-49880

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: fix warning in &amp;#39;ext4_da_release_space&amp;#39;<br /> <br /> Syzkaller report issue as follows:<br /> EXT4-fs (loop0): Free/Dirty block details<br /> EXT4-fs (loop0): free_blocks=0<br /> EXT4-fs (loop0): dirty_blocks=0<br /> EXT4-fs (loop0): Block reservation details<br /> EXT4-fs (loop0): i_reserved_data_blocks=0<br /> EXT4-fs warning (device loop0): ext4_da_release_space:1527: ext4_da_release_space: ino 18, to_free 1 with only 0 reserved data blocks<br /> ------------[ cut here ]------------<br /> WARNING: CPU: 0 PID: 92 at fs/ext4/inode.c:1528 ext4_da_release_space+0x25e/0x370 fs/ext4/inode.c:1524<br /> Modules linked in:<br /> CPU: 0 PID: 92 Comm: kworker/u4:4 Not tainted 6.0.0-syzkaller-09423-g493ffd6605b2 #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022<br /> Workqueue: writeback wb_workfn (flush-7:0)<br /> RIP: 0010:ext4_da_release_space+0x25e/0x370 fs/ext4/inode.c:1528<br /> RSP: 0018:ffffc900015f6c90 EFLAGS: 00010296<br /> RAX: 42215896cd52ea00 RBX: 0000000000000000 RCX: 42215896cd52ea00<br /> RDX: 0000000000000000 RSI: 0000000080000001 RDI: 0000000000000000<br /> RBP: 1ffff1100e907d96 R08: ffffffff816aa79d R09: fffff520002bece5<br /> R10: fffff520002bece5 R11: 1ffff920002bece4 R12: ffff888021fd2000<br /> R13: ffff88807483ecb0 R14: 0000000000000001 R15: ffff88807483e740<br /> FS: 0000000000000000(0000) GS:ffff8880b9a00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00005555569ba628 CR3: 000000000c88e000 CR4: 00000000003506f0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> ext4_es_remove_extent+0x1ab/0x260 fs/ext4/extents_status.c:1461<br /> mpage_release_unused_pages+0x24d/0xef0 fs/ext4/inode.c:1589<br /> ext4_writepages+0x12eb/0x3be0 fs/ext4/inode.c:2852<br /> do_writepages+0x3c3/0x680 mm/page-writeback.c:2469<br /> __writeback_single_inode+0xd1/0x670 fs/fs-writeback.c:1587<br /> writeback_sb_inodes+0xb3b/0x18f0 fs/fs-writeback.c:1870<br /> wb_writeback+0x41f/0x7b0 fs/fs-writeback.c:2044<br /> wb_do_writeback fs/fs-writeback.c:2187 [inline]<br /> wb_workfn+0x3cb/0xef0 fs/fs-writeback.c:2227<br /> process_one_work+0x877/0xdb0 kernel/workqueue.c:2289<br /> worker_thread+0xb14/0x1330 kernel/workqueue.c:2436<br /> kthread+0x266/0x300 kernel/kthread.c:376<br /> ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306<br /> <br /> <br /> Above issue may happens as follows:<br /> ext4_da_write_begin<br /> ext4_create_inline_data<br /> ext4_clear_inode_flag(inode, EXT4_INODE_EXTENTS);<br /> ext4_set_inode_flag(inode, EXT4_INODE_INLINE_DATA);<br /> __ext4_ioctl<br /> ext4_ext_migrate -&gt; will lead to eh-&gt;eh_entries not zero, and set extent flag<br /> ext4_da_write_begin<br /> ext4_da_convert_inline_data_to_extent<br /> ext4_da_write_inline_data_begin<br /> ext4_da_map_blocks<br /> ext4_insert_delayed_block<br /> if (!ext4_es_scan_clu(inode, &amp;ext4_es_is_delonly, lblk))<br /> if (!ext4_es_scan_clu(inode, &amp;ext4_es_is_mapped, lblk))<br /> ext4_clu_mapped(inode, EXT4_B2C(sbi, lblk)); -&gt; will return 1<br /> allocated = true;<br /> ext4_es_insert_delayed_block(inode, lblk, allocated);<br /> ext4_writepages<br /> mpage_map_and_submit_extent(handle, &amp;mpd, &amp;give_up_on_write); -&gt; return -ENOSPC<br /> mpage_release_unused_pages(&amp;mpd, give_up_on_write); -&gt; give_up_on_write == 1<br /> ext4_es_remove_extent<br /> ext4_da_release_space(inode, reserved);<br /> if (unlikely(to_free &gt; ei-&gt;i_reserved_data_blocks))<br /> -&gt; to_free == 1 but ei-&gt;i_reserved_data_blocks == 0<br /> -&gt; then trigger warning as above<br /> <br /> To solve above issue, forbid inode do migrate which has inline data.