CVE-2022-49880

In the Linux kernel, the following vulnerability has been resolved:

ext4: fix warning in 'ext4darelease_space'

Syzkaller report issue as follows: EXT4-fs (loop0): Free/Dirty block details EXT4-fs (loop0): freeblocks=0 EXT4-fs (loop0): dirtyblocks=0 EXT4-fs (loop0): Block reservation details EXT4-fs (loop0): ireserveddatablocks=0 EXT4-fs warning (device loop0): ext4dareleasespace:1527: ext4dareleasespace: ino 18, tofree 1 with only 0 reserved data blocks ------------[ cut here ]------------ WARNING: CPU: 0 PID: 92 at fs/ext4/inode.c:1528 ext4dareleasespace+0x25e/0x370 fs/ext4/inode.c:1524 Modules linked in: CPU: 0 PID: 92 Comm: kworker/u4:4 Not tainted 6.0.0-syzkaller-09423-g493ffd6605b2 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022 Workqueue: writeback wbworkfn (flush-7:0) RIP: 0010:ext4dareleasespace+0x25e/0x370 fs/ext4/inode.c:1528 RSP: 0018:ffffc900015f6c90 EFLAGS: 00010296 RAX: 42215896cd52ea00 RBX: 0000000000000000 RCX: 42215896cd52ea00 RDX: 0000000000000000 RSI: 0000000080000001 RDI: 0000000000000000 RBP: 1ffff1100e907d96 R08: ffffffff816aa79d R09: fffff520002bece5 R10: fffff520002bece5 R11: 1ffff920002bece4 R12: ffff888021fd2000 R13: ffff88807483ecb0 R14: 0000000000000001 R15: ffff88807483e740 FS: 0000000000000000(0000) GS:ffff8880b9a00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005555569ba628 CR3: 000000000c88e000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> ext4esremoveextent+0x1ab/0x260 fs/ext4/extentsstatus.c:1461 mpagereleaseunusedpages+0x24d/0xef0 fs/ext4/inode.c:1589 ext4writepages+0x12eb/0x3be0 fs/ext4/inode.c:2852 dowritepages+0x3c3/0x680 mm/page-writeback.c:2469 _writebacksingleinode+0xd1/0x670 fs/fs-writeback.c:1587 writebacksbinodes+0xb3b/0x18f0 fs/fs-writeback.c:1870 wbwriteback+0x41f/0x7b0 fs/fs-writeback.c:2044 wbdowriteback fs/fs-writeback.c:2187 [inline] wbworkfn+0x3cb/0xef0 fs/fs-writeback.c:2227 processonework+0x877/0xdb0 kernel/workqueue.c:2289 workerthread+0xb14/0x1330 kernel/workqueue.c:2436 kthread+0x266/0x300 kernel/kthread.c:376 retfromfork+0x1f/0x30 arch/x86/entry/entry_64.S:306 </TASK>

Above issue may happens as follows: ext4dawritebegin ext4createinlinedata ext4clearinodeflag(inode, EXT4INODEEXTENTS); ext4setinodeflag(inode, EXT4INODEINLINEDATA); _ext4ioctl ext4extmigrate -> will lead to eh->ehentries not zero, and set extent flag ext4dawritebegin ext4daconvertinlinedatatoextent ext4dawriteinlinedatabegin ext4damapblocks ext4insertdelayedblock if (!ext4esscanclu(inode, &ext4esisdelonly, lblk)) if (!ext4esscanclu(inode, &ext4esismapped, lblk)) ext4clumapped(inode, EXT4B2C(sbi, lblk)); -> will return 1 allocated = true; ext4esinsertdelayedblock(inode, lblk, allocated); ext4writepages mpagemapandsubmitextent(handle, &mpd, &giveuponwrite); -> return -ENOSPC mpagereleaseunusedpages(&mpd, giveuponwrite); -> giveuponwrite == 1 ext4esremoveextent ext4dareleasespace(inode, reserved); if (unlikely(tofree > ei->ireserveddatablocks)) -> tofree == 1 but ei->ireserveddatablocks == 0 -> then trigger warning as above

To solve above issue, forbid inode do migrate which has inline data.