CVE-2023-52622: ext4: avoid online resizing failures due to oversized flex bg

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 flexbgsize,

mkfs.ext4 -F -G 67108864 $dev -b 4096 100M mount $dev $dir resize2fs $dev 16G

the following WARNON is triggered: ================================================================== WARNING: CPU: 0 PID: 427 at mm/pagealloc.c:4402 allocpages+0x411/0x550 Modules linked in: sg(E) CPU: 0 PID: 427 Comm: resize2fs Tainted: G E 6.6.0-rc5+ #314 RIP: 0010:allocpages+0x411/0x550 Call Trace: kmalloclargenode+0xa2/0x200 kmalloc+0x16e/0x290 ext4resizefs+0x481/0xd80 ext4ioctl+0x1616/0x1d90 ext4ioctl+0x12/0x20 x64sysioctl+0xf0/0x150 dosyscall64+0x3b/0x90 ==================================================================

This is because flexbgsize is too large and the size of the newgroupdata array to be allocated exceeds MAXORDER. Currently, the minimum value of MAXORDER is 8, the minimum value of PAGESIZE is 4096, the corresponding maximum number of groups that can be allocated is:

(PAGESIZE << MAXORDER) / sizeof(struct ext4newgroupdata) ≈ 21845

And the value that is down-aligned to the power of 2 is 16384. Therefore, this value is defined as MAXRESIZEBG, 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 flexbg may be more dispersed.

— IBM

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 flexbgsize,

mkfs.ext4 -F -G 67108864 $dev -b 4096 100M mount $dev $dir resize2fs $dev 16G

the following WARNON is triggered: ================================================================== WARNING: CPU: 0 PID: 427 at mm/pagealloc.c:4402 allocpages+0x411/0x550 Modules linked in: sg(E) CPU: 0 PID: 427 Comm: resize2fs Tainted: G E 6.6.0-rc5+ #314 RIP: 0010:allocpages+0x411/0x550 Call Trace: <TASK> kmalloclargenode+0xa2/0x200 kmalloc+0x16e/0x290 ext4resizefs+0x481/0xd80 ext4ioctl+0x1616/0x1d90 ext4ioctl+0x12/0x20 x64sysioctl+0xf0/0x150 dosyscall64+0x3b/0x90 ==================================================================

This is because flexbgsize is too large and the size of the newgroupdata array to be allocated exceeds MAXORDER. Currently, the minimum value of MAXORDER is 8, the minimum value of PAGESIZE is 4096, the corresponding maximum number of groups that can be allocated is:

(PAGESIZE << MAXORDER) / sizeof(struct ext4newgroupdata) ≈ 21845

And the value that is down-aligned to the power of 2 is 16384. Therefore, this value is defined as MAXRESIZEBG, 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 flexbg may be more dispersed.

— NVD