CVE-2024-46847 in Linux
Summary
by MITRE • 09/27/2024
In the Linux kernel, the following vulnerability has been resolved:
mm: vmalloc: ensure vmap_block is initialised before adding to queue
Commit 8c61291fd850 ("mm: fix incorrect vbq reference in purge_fragmented_block") extended the 'vmap_block' structure to contain a 'cpu' field which is set at allocation time to the id of the initialising CPU.
When a new 'vmap_block' is being instantiated by new_vmap_block(), the partially initialised structure is added to the local 'vmap_block_queue' xarray before the 'cpu' field has been initialised. If another CPU is concurrently walking the xarray (e.g. via vm_unmap_aliases()), then it may perform an out-of-bounds access to the remote queue thanks to an uninitialised index.
This has been observed as UBSAN errors in Android:
| Internal error: UBSAN: array index out of bounds: 00000000f2005512 [#1] PREEMPT SMP
| | Call trace: | purge_fragmented_block+0x204/0x21c | _vm_unmap_aliases+0x170/0x378 | vm_unmap_aliases+0x1c/0x28 | change_memory_common+0x1dc/0x26c | set_memory_ro+0x18/0x24 | module_enable_ro+0x98/0x238 | do_init_module+0x1b0/0x310
Move the initialisation of 'vb->cpu' in new_vmap_block() ahead of the addition to the xarray.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 04/05/2026
The vulnerability described in CVE-2024-46847 resides within the Linux kernel's memory management subsystem, specifically in the virtual memory allocation mechanism known as vmalloc. This flaw manifests in the vmap_block data structure initialization process, which is critical for managing virtual memory mappings. The issue occurs during the creation of new vmap_block structures through the new_vmap_block() function, where a race condition can lead to memory corruption and undefined behavior. The vulnerability is particularly concerning because it affects the core memory management operations that underpin system stability and security.
The technical flaw stems from the improper ordering of operations within the new_vmap_block() function where a partially initialized vmap_block structure is added to the local vmap_block_queue xarray before the cpu field is properly initialized. This design flaw creates a scenario where concurrent CPU threads accessing the xarray can encounter uninitialized memory references, leading to out-of-bounds memory access patterns. The cpu field, which is set to the initializing CPU id at allocation time, becomes crucial for proper memory management operations. When another CPU thread traverses the xarray containing these partially initialized structures, it accesses an uninitialized index value that can result in memory corruption.
The operational impact of this vulnerability is significant, particularly in multi-core systems where concurrent memory management operations are common. The vulnerability has been observed as UBSAN (Undefined Behavior Sanitizer) errors in Android environments, indicating that it can trigger memory safety violations that may lead to system crashes or unpredictable behavior. The call trace shows the error propagating through the memory management stack including purge_fragmented_block, vm_unmap_aliases, and module memory operations, demonstrating how this flaw can affect critical kernel subsystems. The vulnerability essentially creates a race condition where memory access patterns become unpredictable due to uninitialized data structures being processed concurrently.
This vulnerability aligns with CWE-457: Use of Uninitialized Variable and CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization, both of which are fundamental security concerns in kernel development. From an ATT&CK perspective, this vulnerability could be leveraged for privilege escalation or denial of service attacks, as it affects the kernel's core memory management functions that are essential for system operation. The fix implemented addresses the root cause by reordering the initialization sequence to ensure that vb->cpu is initialized before the structure is added to the xarray, thereby preventing concurrent access to uninitialized memory regions. This solution follows established best practices for concurrent programming in kernel space where proper ordering of operations is critical for maintaining memory safety and system integrity.
The mitigation strategy focuses on correcting the initialization order within the kernel source code, specifically moving the cpu field initialization ahead of the xarray addition operation. This simple but critical change ensures that all memory access patterns through the vmap_block_queue are safe from uninitialized memory references. System administrators should update to kernel versions containing this fix, as the vulnerability affects systems running Linux kernel versions that include the problematic commit. The fix represents a defensive programming approach that prevents race conditions in kernel memory management, aligning with security best practices for maintaining system stability and preventing potential exploitation scenarios.