CVE-2023-52622 is a vulnerability in the Linux kernel's ext4 filesystem implementation related to online resizing operations when using an oversized flex_bg (flexible block group) size. The ext4 filesystem supports online resizing, allowing the filesystem to be expanded while mounted. However, when the flex_bg_size parameter is set excessively large, the resize2fs tool triggers a kernel warning and potential failure during the allocation of new group metadata structures. Specifically, the issue arises because the allocation size for the new_group_data array exceeds the kernel's MAX_ORDER limit, which restricts the maximum order of pages that can be allocated in a single contiguous block. The kernel's memory allocator cannot fulfill this request, causing a WARN_ON in the __alloc_pages function, which is a sign of a critical memory allocation failure. The vulnerability is triggered by commands such as creating an ext4 filesystem with an extremely large flex_bg_size (e.g., 67108864), mounting it, and then attempting to resize it online to a much larger size (e.g., 16G). The root cause is that the ext4 resize code does not properly limit the number of groups added in one step, leading to oversized allocations. The fix involves defining a MAX_RESIZE_BG value (16384 groups) that limits the number of groups added per resize operation, breaking the resize into multiple smaller steps to avoid exceeding MAX_ORDER. This ensures that metadata allocations remain within kernel limits and prevents the WARN_ON and potential instability during resizing. No known exploits are reported in the wild, and the vulnerability is primarily a stability and denial-of-service risk during filesystem resizing operations. It requires privileged access to perform filesystem resizing and is not triggered by normal filesystem usage or unprivileged users.

For European organizations, this vulnerability primarily poses a risk to systems running Linux with ext4 filesystems that perform online resizing operations with unusually large flex_bg_size parameters. The impact is mostly limited to system stability and availability during resizing, as the kernel warning indicates a failure in memory allocation that could cause the resize operation to fail or the system to become unstable temporarily. This could lead to denial of service on critical servers or storage systems undergoing maintenance or dynamic resizing, potentially affecting database servers, file servers, or cloud infrastructure nodes that rely on ext4 and dynamic storage management. Since exploitation requires privileged access and specific conditions (oversized flex_bg_size and online resizing), the risk of widespread disruption is moderate. However, organizations with automated or scripted resizing processes that might use large flex_bg_size values could inadvertently trigger this issue, causing operational disruptions. The vulnerability does not directly expose confidentiality or integrity risks but could indirectly impact availability of critical services. European enterprises with large-scale Linux deployments, especially in cloud, hosting, or data center environments, should be aware of this issue to avoid unexpected downtime during filesystem maintenance.

1. Avoid using excessively large flex_bg_size values when creating ext4 filesystems. Stick to default or recommended flex_bg_size settings to prevent triggering this condition. 2. Apply the Linux kernel patch that introduces the MAX_RESIZE_BG limit to ensure that online resizing operations are broken into smaller, manageable steps that do not exceed memory allocation limits. 3. Test any automated or manual filesystem resizing procedures in a controlled environment to verify they do not trigger this vulnerability. 4. Monitor kernel logs for WARN_ON messages related to __alloc_pages during resize2fs operations, which could indicate attempts to resize with oversized flex_bg_size. 5. Restrict filesystem resizing operations to trusted administrators and ensure proper change management to prevent accidental misuse. 6. Consider alternative filesystem types or offline resizing if large-scale resizing is required and cannot be safely performed online. 7. Keep Linux kernel versions up to date with security patches and monitor vendor advisories for backported fixes related to ext4 resizing.