CVE-2024-43892 in Linux
Summary
by MITRE • 08/26/2024
In the Linux kernel, the following vulnerability has been resolved:
memcg: protect concurrent access to mem_cgroup_idr
Commit 73f576c04b94 ("mm: memcontrol: fix cgroup creation failure after many small jobs") decoupled the memcg IDs from the CSS ID space to fix the cgroup creation failures. It introduced IDR to maintain the memcg ID space. The IDR depends on external synchronization mechanisms for modifications. For the mem_cgroup_idr, the idr_alloc() and idr_replace() happen within css callback and thus are protected through cgroup_mutex from concurrent modifications. However idr_remove() for mem_cgroup_idr was not protected against concurrency and can be run concurrently for different memcgs when they hit their refcnt to zero. Fix that.
We have been seeing list_lru based kernel crashes at a low frequency in our fleet for a long time. These crashes were in different part of list_lru code including list_lru_add(), list_lru_del() and reparenting code. Upon further inspection, it looked like for a given object (dentry and inode), the super_block's list_lru didn't have list_lru_one for the memcg of that object. The initial suspicions were either the object is not allocated through kmem_cache_alloc_lru() or somehow memcg_list_lru_alloc() failed to allocate list_lru_one() for a memcg but returned success. No evidence were found for these cases.
Looking more deeply, we started seeing situations where valid memcg's id is not present in mem_cgroup_idr and in some cases multiple valid memcgs have same id and mem_cgroup_idr is pointing to one of them. So, the most reasonable explanation is that these situations can happen due to race between multiple idr_remove() calls or race between idr_alloc()/idr_replace() and idr_remove(). These races are causing multiple memcgs to acquire the same ID and then offlining of one of them would cleanup list_lrus on the system for all of them. Later access from other memcgs to the list_lru cause crashes due to missing list_lru_one.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/29/2025
The vulnerability described in CVE-2024-43892 represents a critical concurrency issue within the Linux kernel's memory control group (memcg) subsystem that can lead to system instability and potential crashes. This flaw specifically affects the management of memory cgroup identifiers through the mem_cgroup_idr data structure, which was introduced to decouple memcg IDs from the CSS ID space as part of commit 73f576c04b94. The issue stems from inadequate protection mechanisms around the idr_remove() operation within the mem_cgroup_idr, creating race conditions that can result in multiple memory cgroups erroneously sharing the same identifier.
The technical root cause of this vulnerability lies in the inconsistent synchronization of operations within the memory control group subsystem. While idr_alloc() and idr_replace() operations are properly protected by the cgroup_mutex within CSS callbacks, the idr_remove() function lacks equivalent concurrency protection. This asymmetry creates a window where multiple concurrent operations can modify the mem_cgroup_idr simultaneously, leading to scenarios where valid memory cgroups may lose their unique identifiers or where different cgroups end up with identical IDs. The vulnerability manifests as a race condition between multiple idr_remove() calls or between idr_alloc()/idr_replace() operations and idr_remove() operations, which can cause memory cgroups to acquire the same identifier and subsequently have their list_lru structures improperly cleaned up when one of them is offlined.
The operational impact of this vulnerability extends beyond simple memory management issues to potentially destabilize entire systems through kernel crashes. The described crashes occur within list_lru based kernel code, specifically affecting list_lru_add(), list_lru_del(), and reparenting operations. These failures result in system instability where valid objects such as dentries and inodes cannot properly access their associated super_block's list_lru structures because the memcg's list_lru_one is missing from the system. This condition creates a cascading failure where access to memory cgroup list_lru structures causes crashes due to missing list_lru_one entries, effectively compromising the kernel's ability to manage memory cgroup relationships properly. The vulnerability's low-frequency occurrence makes it particularly dangerous as it may go unnoticed during normal operation but can cause catastrophic failures when triggered under specific concurrent access patterns.
The implications of this vulnerability align with CWE-362, which addresses race conditions in concurrent programming, and relates to ATT&CK technique T1490, which involves data destruction through system resource exhaustion or corruption. The flaw demonstrates how seemingly isolated synchronization issues within kernel subsystems can lead to widespread system instability, particularly in environments with high concurrent memory management operations. The memory cgroup subsystem's design failure creates a situation where the integrity of the ID space management is compromised, leading to cascading failures throughout the kernel's memory management infrastructure. Mitigation strategies should focus on implementing proper locking mechanisms around the idr_remove() operations within the mem_cgroup_idr, ensuring that all modifications to this critical data structure are properly synchronized to prevent the race conditions that lead to multiple memory cgroups sharing identifiers and subsequent system crashes.