CVE-2022-49360

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

f2fs: fix to do sanity check on total_data_blocks

As Yanming reported in bugzilla:

https://bugzilla.kernel.org/show_bug.cgi?id=215916

The kernel message is shown below:

kernel BUG at fs/f2fs/segment.c:2560!

Call Trace:

allocate_segment_by_default+0x228/0x440

f2fs_allocate_data_block+0x13d1/0x31f0

do_write_page+0x18d/0x710

f2fs_outplace_write_data+0x151/0x250

f2fs_do_write_data_page+0xef9/0x1980

move_data_page+0x6af/0xbc0

do_garbage_collect+0x312f/0x46f0

f2fs_gc+0x6b0/0x3bc0

f2fs_balance_fs+0x921/0x2260

f2fs_write_single_data_page+0x16be/0x2370

f2fs_write_cache_pages+0x428/0xd00

f2fs_write_data_pages+0x96e/0xd50

do_writepages+0x168/0x550

__writeback_single_inode+0x9f/0x870

writeback_sb_inodes+0x47d/0xb20

__writeback_inodes_wb+0xb2/0x200

wb_writeback+0x4bd/0x660

wb_workfn+0x5f3/0xab0

process_one_work+0x79f/0x13e0

worker_thread+0x89/0xf60

kthread+0x26a/0x300

ret_from_fork+0x22/0x30

RIP: 0010:new_curseg+0xe8d/0x15f0

The root cause is: ckpt.valid_block_count is inconsistent with SIT table,

stat info indicates filesystem has free blocks, but SIT table indicates

filesystem has no free segment.

So that during garbage colloection, it triggers panic when LFS allocator

fails to find free segment.

This patch tries to fix this issue by checking consistency in between

ckpt.valid_block_count and block accounted from SIT.