LiveActive security incident?Get immediate response
CVE Record

CVE-2024-43892: memcg: protect concurrent access to mem_cgroup_idr

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.

UnknownCVSS not scoredNot KEV-listedUpdated
Discuss exposureBack to CVEs
Glexia's TakeAutomated analysismoderate

Security readout for executives and security teams

Plain-English summary

This Linux kernel issue can cause rare but serious kernel crashes when memory cgroup IDs are changed concurrently. For businesses, the main concern is host availability: affected systems, especially container or workload-heavy Linux hosts, may crash unexpectedly. No source in the bundle reports active exploitation.

Executive priority

Schedule remediation through the normal Linux kernel patch cycle, with faster handling for production container platforms or hosts showing unexplained kernel crashes. Lack of known exploitation lowers emergency pressure, but kernel crash impact justifies timely patching.

Technical view

The bug is a race around mem_cgroup_idr. Some IDR removals were not synchronized with other removals or allocations, allowing valid memory cgroups to lose or share IDs. Later list_lru cleanup for one cgroup can corrupt assumptions for another, causing kernel crashes in list_lru paths.

Likely exposure

Exposure is most likely on Linux systems using affected kernel builds with memory cgroups, especially container, CI, or batch environments with frequent cgroup creation and deletion. Distro backports may change exposure, so version strings alone are not sufficient.

Exploitation context

The source bundle marks KEV as false and provides no evidence of active exploitation or public weaponization. The kernel description discusses low-frequency fleet crashes caused by concurrency races, not an attacker workflow. Treat this primarily as an availability and reliability risk.

Researcher notes

The evidence supports a concurrency bug in memcg ID management, not a demonstrated privilege escalation path. Important unknowns include exploitability, trigger reliability outside observed fleet conditions, and distro-specific affected package ranges. Avoid assuming exposure without vendor backport confirmation.

Mitigation direction

  • Apply vendor or distribution kernel updates that include the referenced stable fixes.
  • Check Debian LTS advisories if running Debian-based long-term support kernels.
  • Prioritize container hosts and systems with high cgroup churn.
  • Monitor vendor security notices for exact fixed package versions.
  • Use vendor guidance if immediate patching is not possible.

Validation and detection

  • Inventory Linux kernel versions and distribution package revisions across affected fleets.
  • Confirm whether vendor changelogs mention CVE-2024-43892 or the stable fix commits.
  • Review kernel crash logs for list_lru, memcg, or cgroup-related panics.
  • Validate patched kernels first on representative container or batch workload hosts.
Prepared
Confidence
medium
Sources
10

Public sources used

Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.

Potential ATT&CK relevance

Conservative CVE-to-ATT&CK context

These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.

ATT&CK lookup starting points

Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.

cve · low confidence lookup

CVE-2024-43892 mapping review

Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.

Open ATT&CK lookup
Vulnerability profileCVE Program record
Severity
Unknown
CVSS
Not scored
Known Exploited
No
Published
Official CVE source material

CNA and ADP enrichment extracted from CVE v5

These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.

0CVSS vectors
3Timeline events
2ADP providers
9Source links

SSVC decision data

CISA-ADPCISA Coordinator
Timestamp
Version
2.0.3
Exploitation: noneAutomatable: noTechnical Impact: partial

Vulnerability timeline

Timeline events are normalized from CVE metadata, CNA source timelines, ADP timelines, and KEV metadata when present.

  1. CVE reservedCVE Program

    The CVE ID was reserved by the assigning CNA.

  2. CVE publishedCVE Program

    The CVE record was published.

  3. CVE updatedCVE Program

    The CVE record metadata indicates this as the latest update time.

ADP provider summaries

CISA-ADPCISA ADP Vulnrichment
other:ssvc
CVECVE Program Container

Source materials

Affected products

Products and packages named in the record

VendorProductVersion / packageStatus
LinuxLinux73f576c04b9410ed19660f74f97521bee6e1c546, 73f576c04b9410ed19660f74f97521bee6e1c546, 73f576c04b9410ed19660f74f97521bee6e1c546, 73f576c04b9410ed19660f74f97521bee6e1c546, 73f576c04b9410ed19660f74f97521bee6e1c546, 73f576c04b9410ed19660f74f97521bee6e1c546, 8627c7750a66a46d56d3564e1e881aa53764497c, db70cd18d3da727a3a59694de428a9e41c620de7, 4.4.18, 4.6.6unaffected
LinuxLinux4.7, 0, 5.10.226, 5.15.167, 6.1.110, 6.6.46, 6.10.5, 6.11affected
Weakness

CWE details

No CWE listed

CWE links open Glexia weakness intelligence pages with official CWE context, developer remediation guidance, and related CVE mappings.