Incorrect Calculation of Buffer Size Affecting kernel-zfcpdump-modules package, versions <0:4.18.0-553.16.1.el8_10
Threat Intelligence
Do your applications use this vulnerable package?
In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.
Test your applications- Snyk ID SNYK-RHEL8-KERNELZFCPDUMPMODULES-6506430
- published 27 Mar 2024
- disclosed 26 Mar 2024
Introduced: 26 Mar 2024
CVE-2023-52622 Open this link in a new tabHow to fix?
Upgrade RHEL:8 kernel-zfcpdump-modules to version 0:4.18.0-553.16.1.el8_10 or higher.
This issue was patched in RHSA-2024:5101.
NVD Description
Note: Versions mentioned in the description apply only to the upstream kernel-zfcpdump-modules package and not the kernel-zfcpdump-modules package as distributed by RHEL.
See How to fix? for RHEL:8 relevant fixed versions and status.
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.
References
- https://access.redhat.com/security/cve/CVE-2023-52622
- https://git.kernel.org/stable/c/5d1935ac02ca5aee364a449a35e2977ea84509b0
- https://git.kernel.org/stable/c/6d2cbf517dcabc093159cf138ad5712c9c7fa954
- https://git.kernel.org/stable/c/8b1413dbfe49646eda2c00c0f1144ee9d3368e0c
- https://git.kernel.org/stable/c/b183fe8702e78bba3dcef8e7193cab6898abee07
- https://git.kernel.org/stable/c/cd1f93ca97a9136989f3bd2bf90696732a2ed644
- https://git.kernel.org/stable/c/cfbbb3199e71b63fc26cee0ebff327c47128a1e8
- https://git.kernel.org/stable/c/d76c8d7ffe163c6bf2f1ef680b0539c2b3902b90
- https://git.kernel.org/stable/c/dc3e0f55bec4410f3d74352c4a7c79f518088ee2
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html