CVE-2024-26894 in Linux
Summary
by MITRE • 04/17/2024
In the Linux kernel, the following vulnerability has been resolved:
ACPI: processor_idle: Fix memory leak in acpi_processor_power_exit()
After unregistering the CPU idle device, the memory associated with it is not freed, leading to a memory leak:
unreferenced object 0xffff896282f6c000 (size 1024): comm "swapper/0", pid 1, jiffies 4294893170 hex dump (first 32 bytes): 00 00 00 00 0b 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc 8836a742): [] kmalloc_trace+0x29d/0x340
[] acpi_processor_power_init+0xf3/0x1c0
[] __acpi_processor_start+0xd3/0xf0
[] acpi_processor_start+0x2c/0x50
[] really_probe+0xe2/0x480
[] __driver_probe_device+0x78/0x160
[] driver_probe_device+0x1f/0x90
[] __driver_attach+0xce/0x1c0
[] bus_for_each_dev+0x70/0xc0
[] bus_add_driver+0x112/0x210
[] driver_register+0x55/0x100
[] acpi_processor_driver_init+0x3b/0xc0
[] do_one_initcall+0x41/0x300
[] kernel_init_freeable+0x320/0x470
[] kernel_init+0x16/0x1b0
[] ret_from_fork+0x2d/0x50
Fix this by freeing the CPU idle device after unregistering it.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 11/01/2024
The vulnerability identified as CVE-2024-26894 represents a memory leak within the Linux kernel's ACPI processor idle subsystem. This issue occurs specifically during the cleanup phase of CPU idle device management where the kernel fails to properly release memory resources after unregistering these devices. The flaw manifests in the acpi_processor_power_exit() function which is responsible for cleaning up ACPI processor idle infrastructure. When CPU idle devices are unregistered, the associated memory allocation remains unreferenced and therefore cannot be reclaimed by the system's memory management subsystem, leading to gradual memory consumption over time.
The technical root cause of this vulnerability lies in the improper memory management sequence within the kernel's ACPI subsystem. According to CWE-401, this represents a classic memory leak condition where allocated memory is not properly freed, creating a resource exhaustion scenario. The memory leak occurs when the kernel processes the shutdown or cleanup of CPU idle devices without executing the necessary deallocation routine that should occur after device unregistration. This pattern is consistent with improper resource management practices that can be categorized under the ATT&CK technique T1490 for resource exhaustion and T1070 for indicator removal through manipulation of logs and system resources. The leaked memory object measures 1024 bytes and is associated with the kernel's swapper/0 process with PID 1, indicating this affects the most fundamental system processes.
The operational impact of this memory leak extends beyond simple resource waste to potentially degrade system performance and stability over extended periods of operation. While the leak itself may appear small at 1024 bytes per instance, in systems with multiple CPU cores and frequent power management operations, the cumulative effect can lead to significant memory pressure. This vulnerability is particularly concerning in server environments or embedded systems where long uptime periods are expected, as the memory leak compounds over time and could eventually contribute to system instability or performance degradation. The leak is triggered during kernel initialization and device probing phases, making it particularly problematic during system boot processes or when hot-plugging CPU devices, as it can cause memory allocation failures and system resource exhaustion.
Mitigation strategies for this vulnerability should focus on immediate kernel updates to versions containing the fix, which properly implements the memory deallocation after CPU idle device unregistration. System administrators should prioritize applying patches from their respective Linux distributions, as this vulnerability affects the core kernel functionality and can be exploited in environments where memory exhaustion leads to denial of service conditions. The fix aligns with best practices for kernel memory management and follows established security protocols for resource cleanup in device drivers. Additionally, monitoring systems for memory usage patterns and implementing automated alerting for memory pressure conditions can help detect and respond to potential exploitation of this vulnerability, though the most effective mitigation remains the application of the official kernel patch that addresses the root cause of the memory leak in the ACPI processor idle subsystem.