CVE-2023-52622

In the Linux kernel, the following vulnerability has been resolved: ext4:
avoid online resizing failures due to oversized flex bg When we online
resize an ext4 filesystem with a oversized flexbg_size, mkfs.ext4 -F -G
67108864 $dev -b 4096 100M mount $dev $dir resize2fs $dev 16G the following
WARN_ON is triggered:
================================================================== WARNING:
CPU: 0 PID: 427 at mm/page_alloc.c:4402 __alloc_pages+0x411/0x550 Modules
linked in: sg(E) CPU: 0 PID: 427 Comm: resize2fs Tainted: G E 6.6.0-rc5+
#314 RIP: 0010:__alloc_pages+0x411/0x550 Call Trace: <TASK>
__kmalloc_large_node+0xa2/0x200 __kmalloc+0x16e/0x290
ext4_resize_fs+0x481/0xd80 __ext4_ioctl+0x1616/0x1d90 ext4_ioctl+0x12/0x20
__x64_sys_ioctl+0xf0/0x150 do_syscall_64+0x3b/0x90
================================================================== This is
because flexbg_size is too large and the size of the new_group_data array
to be allocated exceeds MAX_ORDER. Currently, the minimum value of
MAX_ORDER is 8, the minimum value of PAGE_SIZE is 4096, the corresponding
maximum number of groups that can be allocated is: (PAGE_SIZE << MAX_ORDER)
/ sizeof(struct ext4_new_group_data) ≈ 21845 And the value that is
down-aligned to the power of 2 is 16384. Therefore, this value is defined
as MAX_RESIZE_BG, and the number of groups added each time does not exceed
this value during resizing, and is added multiple times to complete the
online resizing. The difference is that the metadata in a flex_bg may be
more dispersed.

Notes