CVE-2022-49549 in Linux
Summary
by MITRE • 02/26/2025
In the Linux kernel, the following vulnerability has been resolved:
x86/MCE/AMD: Fix memory leak when threshold_create_bank() fails
In mce_threshold_create_device(), if threshold_create_bank() fails, the previously allocated threshold banks array @bp will be leaked because the call to mce_threshold_remove_device() will not free it.
This happens because mce_threshold_remove_device() fetches the pointer through the threshold_banks per-CPU variable but bp is written there only after the bank creation is successful, and not before, when threshold_create_bank() fails.
Add a helper which unwinds all the bank creation work previously done and pass into it the previously allocated threshold banks array for freeing.
[ bp: Massage. ]
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 06/12/2025
The vulnerability identified as CVE-2022-49549 represents a memory leak condition within the Linux kernel's memory error correction subsystem, specifically affecting x86 architectures with AMD processors. This flaw exists in the machine check exception (MCE) handling mechanism that monitors and manages hardware memory errors. The issue manifests during the initialization of threshold-based memory error monitoring devices where the kernel attempts to create and configure memory error detection banks. When the threshold_create_bank() function fails during this process, the system fails to properly clean up previously allocated memory resources, leading to a persistent memory leak that can accumulate over time and potentially impact system stability and performance.
The technical root cause of this vulnerability stems from improper resource management within the mce_threshold_create_device() function. During the device creation process, the kernel allocates memory for threshold banks through the bp pointer, but this allocation occurs only after successful completion of threshold_create_bank() operations. When this function fails, the allocated memory in the @bp array remains unreleased because the cleanup routine mce_threshold_remove_device() only accesses the threshold_banks array through per-CPU variables that are populated only upon successful bank creation. This creates a classic resource leak scenario where allocated memory is not properly deallocated, violating fundamental memory management principles and potentially leading to memory exhaustion under sustained error conditions.
The operational impact of this vulnerability extends beyond simple memory consumption, as it represents a potential denial of service condition that could degrade system performance or cause unexpected system behavior. While the immediate effects may appear minor in single instances, repeated failures in memory error monitoring initialization could lead to progressive memory consumption that impacts overall system responsiveness. The vulnerability affects systems running Linux kernels with AMD processors that implement machine check exception handling, particularly those utilizing the threshold-based memory error monitoring capabilities. Attackers could potentially exploit this condition by repeatedly triggering memory error scenarios that cause the threshold creation process to fail, leading to progressive memory exhaustion and system instability.
This memory leak vulnerability aligns with CWE-401, which specifically addresses "Improper Release of Memory before Removal from Ownership" and relates to the broader category of resource management flaws in kernel space. The issue demonstrates poor defensive programming practices where error handling paths fail to account for partially completed resource allocation sequences, creating a scenario where cleanup operations cannot properly access previously allocated resources. From an ATT&CK perspective, this vulnerability could be leveraged as part of a resource exhaustion attack pattern, potentially enabling adversaries to degrade system performance or availability through sustained exploitation of the memory leak condition. The vulnerability requires no special privileges to manifest, making it particularly concerning as it can be triggered through normal system operation or by any process that generates memory error conditions that cause the threshold creation to fail.
The fix for this vulnerability involves implementing a dedicated helper function that properly unwinds all previously completed bank creation operations and ensures that the allocated threshold banks array is properly freed when threshold_create_bank() fails. This approach follows established kernel development practices for error handling and resource cleanup, ensuring that all allocated resources are properly released regardless of whether the operation completes successfully or fails. The solution addresses the fundamental flaw in the resource management flow by ensuring that cleanup operations have access to all previously allocated memory, preventing the accumulation of leaked memory that could otherwise impact system stability. This remediation aligns with best practices for kernel memory management and error handling, ensuring that system resources are properly accounted for and released even in failure scenarios.