CVE-2022-49080 in Linux
Summary
by MITRE • 02/26/2025
In the Linux kernel, the following vulnerability has been resolved:
mm/mempolicy: fix mpol_new leak in shared_policy_replace
If mpol_new is allocated but not used in restart loop, mpol_new will be freed via mpol_put before returning to the caller. But refcnt is not initialized yet, so mpol_put could not do the right things and might leak the unused mpol_new. This would happen if mempolicy was updated on the shared shmem file while the sp->lock has been dropped during the memory allocation.
This issue could be triggered easily with the below code snippet if there are many processes doing the below work at the same time:
shmid = shmget((key_t)5566, 1024 * PAGE_SIZE, 0666|IPC_CREAT); shm = shmat(shmid, 0, 0); loop many times {
mbind(shm, 1024 * PAGE_SIZE, MPOL_LOCAL, mask, maxnode, 0); mbind(shm + 128 * PAGE_SIZE, 128 * PAGE_SIZE, MPOL_DEFAULT, mask, maxnode, 0); }
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/24/2025
The vulnerability CVE-2022-49080 resides within the Linux kernel's memory management subsystem, specifically in the memory policy handling mechanism known as mempolicy. This flaw manifests in the mm/mempolicy component where the kernel manages memory allocation policies for shared memory segments. The issue stems from improper reference counting initialization during the shared policy replacement process, creating a potential memory leak scenario that could be exploited through concurrent memory management operations.
The technical flaw occurs when the mpol_new function allocates memory for a new memory policy structure but fails to properly initialize its reference counter before entering a restart loop. When the shared memory policy is updated on a shared shmem file while the sp->lock has been temporarily dropped during memory allocation, the system attempts to free the unused mpol_new structure through mpol_put. However, due to the uninitialized reference counter, the mpol_put function cannot correctly determine whether the structure should be freed or if it's still in use, leading to a memory leak where the allocated structure remains in memory even though it's no longer needed.
This vulnerability creates a significant operational impact by allowing memory leaks to accumulate over time, particularly in environments with high concurrency and frequent memory policy updates. The issue is particularly dangerous in multi-process environments where many concurrent processes perform repeated memory binding operations on shared memory segments. The leak occurs during the shared_policy_replace function when the system handles memory policy updates on shared memory files, making it a critical concern for systems handling large numbers of concurrent memory management operations.
The exploitability of this vulnerability is enhanced by the specific conditions required for triggering the memory leak, which involve concurrent access patterns and the precise timing of lock releases during memory allocation. Attackers can leverage this flaw by creating scenarios with multiple processes simultaneously performing memory binding operations on shared memory segments, causing the reference counting mechanism to fail and resulting in gradual memory consumption. This aligns with CWE-401, which addresses improper handling of memory allocation failures and resource leaks in kernel code. The vulnerability demonstrates characteristics consistent with ATT&CK technique T1059.003, where adversaries might exploit system-level memory management flaws to maintain persistent access or cause resource exhaustion.
Mitigation strategies should focus on ensuring proper reference counter initialization before memory allocation operations and implementing robust error handling in memory policy update functions. Kernel patches should enforce proper reference counting mechanisms and ensure that mpol_new structures are correctly initialized before entering restart loops. System administrators should monitor for unusual memory consumption patterns and consider implementing process limits to prevent excessive concurrent memory policy operations. The fix involves modifying the shared_policy_replace function to properly initialize reference counters before entering the restart loop, ensuring that mpol_put can correctly determine when memory structures should be freed. Additionally, implementing proper locking mechanisms and reducing the window of opportunity for concurrent access during critical memory allocation phases would significantly reduce the risk of exploitation.