CVE-2024-26983 in Linux
Summary
by MITRE • 05/01/2024
In the Linux kernel, the following vulnerability has been resolved:
bootconfig: use memblock_free_late to free xbc memory to buddy
On the time to free xbc memory in xbc_exit(), memblock may has handed over memory to buddy allocator. So it doesn't make sense to free memory back to memblock. memblock_free() called by xbc_exit() even causes UAF bugs on architectures with CONFIG_ARCH_KEEP_MEMBLOCK disabled like x86. Following KASAN logs shows this case.
This patch fixes the xbc memory free problem by calling memblock_free() in early xbc init error rewind path and calling memblock_free_late() in xbc exit path to free memory to buddy allocator.
[ 9.410890] ==================================================================
[ 9.418962] BUG: KASAN: use-after-free in memblock_isolate_range+0x12d/0x260
[ 9.426850] Read of size 8 at addr ffff88845dd30000 by task swapper/0/1
[ 9.435901] CPU: 9 PID: 1 Comm: swapper/0 Tainted: G U 6.9.0-rc3-00208-g586b5dfb51b9 #5
[ 9.446403] Hardware name: Intel Corporation RPLP LP5 (CPU:RaptorLake)/RPLP LP5 (ID:13), BIOS IRPPN02.01.01.00.00.19.015.D-00000000 Dec 28 2023
[ 9.460789] Call Trace:
[ 9.463518]
[ 9.465859] dump_stack_lvl+0x53/0x70
[ 9.469949] print_report+0xce/0x610
[ 9.473944] ? __virt_addr_valid+0xf5/0x1b0
[ 9.478619] ? memblock_isolate_range+0x12d/0x260
[ 9.483877] kasan_report+0xc6/0x100
[ 9.487870] ? memblock_isolate_range+0x12d/0x260
[ 9.493125] memblock_isolate_range+0x12d/0x260
[ 9.498187] memblock_phys_free+0xb4/0x160
[ 9.502762] ? __pfx_memblock_phys_free+0x10/0x10
[ 9.508021] ? mutex_unlock+0x7e/0xd0
[ 9.512111] ? __pfx_mutex_unlock+0x10/0x10
[ 9.516786] ? kernel_init_freeable+0x2d4/0x430
[ 9.521850] ? __pfx_kernel_init+0x10/0x10
[ 9.526426] xbc_exit+0x17/0x70
[ 9.529935] kernel_init+0x38/0x1e0
[ 9.533829] ? _raw_spin_unlock_irq+0xd/0x30
[ 9.538601] ret_from_fork+0x2c/0x50
[ 9.542596] ? __pfx_kernel_init+0x10/0x10
[ 9.547170] ret_from_fork_asm+0x1a/0x30
[ 9.551552]
[ 9.555649] The buggy address belongs to the physical page:
[ 9.561875] page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x1 pfn:0x45dd30
[ 9.570821] flags: 0x200000000000000(node=0|zone=2)
[ 9.576271] page_type: 0xffffffff()
[ 9.580167] raw: 0200000000000000 ffffea0011774c48 ffffea0012ba1848 0000000000000000
[ 9.588823] raw: 0000000000000001 0000000000000000 00000000ffffffff 0000000000000000
[ 9.597476] page dumped because: kasan: bad access detected
[ 9.605362] Memory state around the buggy address:
[ 9.610714] ffff88845dd2ff00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 9.618786] ffff88845dd2ff80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 9.626857] >ffff88845dd30000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[ 9.634930] ^
[ 9.638534] ffff88845dd30080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[ 9.646605] ffff88845dd30100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[ 9.654675] ==================================================================
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 02/06/2026
The vulnerability described in CVE-2024-26983 affects the Linux kernel's boot configuration handling mechanism, specifically within the xbc (eXtensible Boot Configuration) subsystem. This issue stems from improper memory management during the initialization and cleanup phases of the xbc module, leading to potential use-after-free conditions that can result in system instability or exploitation. The problem manifests when the kernel attempts to free memory allocated for xbc structures, particularly in scenarios where memory has already been handed over to the buddy allocator, which is a core memory management component in the Linux kernel responsible for dynamic memory allocation.
The technical flaw resides in the xbc_exit() function, which incorrectly uses memblock_free() to release memory that has already been transferred to the buddy allocator. This mismanagement creates a scenario where memory operations occur on already freed regions, triggering KASAN (Kernel Address Sanitizer) reports and resulting in use-after-free bugs. The kernel's memory subsystem operates under strict constraints where memory allocated through memblock cannot be freed back to memblock once it has been passed to the buddy allocator, as demonstrated in the KASAN logs showing access to freed memory at address ffff88845dd30000. This condition is particularly critical on architectures like x86 where CONFIG_ARCH_KEEP_MEMBLOCK is disabled, as the memory management paths differ significantly from those with memblock retention enabled.
The operational impact of this vulnerability extends beyond simple memory corruption, potentially enabling privilege escalation or denial-of-service conditions within the kernel. When the xbc subsystem attempts to free memory that has already been managed by the buddy allocator, the system may experience crashes, data corruption, or more sinister exploitation opportunities for attackers who can manipulate the boot process. The vulnerability affects systems running kernel versions that include the problematic xbc implementation, particularly those using recent kernel releases where memory management has been restructured to optimize performance and memory allocation patterns. This issue is classified under CWE-416 as Use After Free, which represents a common and dangerous class of memory safety vulnerabilities in kernel space. The ATT&CK framework would categorize this under T1068 - Exploitation for Privilege Escalation, as successful exploitation could allow an attacker to gain elevated privileges within the kernel.
The fix implemented addresses the core issue by differentiating memory freeing operations based on the execution phase. During early initialization error handling, memblock_free() is used to properly reclaim memory allocated through memblock, while in the xbc_exit() path, memblock_free_late() is employed to correctly return memory to the buddy allocator. This approach ensures that memory management operations occur in the appropriate allocator context, preventing the cross-allocator freeing that caused the use-after-free condition. The patch effectively separates the memory management responsibilities between early boot error recovery and normal cleanup operations, aligning with kernel memory management best practices and ensuring proper resource deallocation without violating the memory subsystem's internal consistency requirements.