CVE-2023-52622

What it actually does

Oversized flexbg_size during ext4 online resize causes new_group_data array allocation to exceed MAX_ORDER, triggering WARN_ON in __alloc_pages and potential kmalloc failure.

Why it matters to the business

Online filesystem resize operations on ext4 can fail or produce kernel warnings, disrupting storage expansion on affected Linux systems; low urgency given false KEV status and stable low EPSS.

How an attack unfolds

Local user invokes resize2fs against an ext4 filesystem previously created with an excessively large flex_bg group count, causing the kernel ext4_resize_fs path to attempt an oversized allocation that exceeds page allocator limits.

How to fix it

Apply the upstream fix that caps groups added per resize iteration at MAX_RESIZE_BG (16384) and performs incremental resizes; update to a kernel containing commit equivalent to the referenced resolution.

How to confirm the fix worked

Confirm kernel version includes the flexbg resize limit check; attempt the reproducer resize sequence and verify absence of the page_alloc WARN_ON.

Typical attack path

1. Create ext4 filesystem with oversized flexbg_size via mkfs.ext4
2. Mount the filesystem
3. Execute resize2fs to a much larger size
4. Trigger allocation of new_group_data exceeding MAX_ORDER

How to detect it

Review kernel logs for the specific __alloc_pages WARN from mm/page_alloc.c during resize2fs or ext4_ioctl activity; inspect audit logs for unusual ext4 resize ioctl calls.

• WARNING: CPU:.*PID:.*at mm/page_alloc.c:4402 __alloc_pages
• ext4_resize_fs
• resize2fs.*16G

What your security team should do

• Prioritize patching ext4 resize code on systems performing frequent online resizes
• Monitor for large flex_bg configurations in mkfs scripts
• Restrict unprivileged use of resize2fs where possible