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.

HighCVSS 7.8Not KEV-listedUpdated
Discuss exposureBack to CVEs
Glexia's TakeAutomated analysishigh

Security readout for executives and security teams

Plain-English summary

A Linux kernel race can corrupt memory-control-group identifiers when multiple groups are removed concurrently. The resulting identifier reuse may make the kernel remove shared bookkeeping for still-active groups, later causing crashes. Because triggering requires local privileges but potential impact includes system compromise or outage, the supplied CVSS rates it 7.8 High.

Executive priority

Treat as a high-priority kernel update, especially for multi-user or workload-dense Linux systems. Schedule prompt remediation through normal tested kernel maintenance. Emergency action is not substantiated because active exploitation is not reported, but the documented fleet crashes show credible availability risk.

Technical view

The mem_cgroup_idr ID allocator requires external synchronization. Allocation and replacement were protected by cgroup_mutex, but removal was not. Concurrent removals, or removal racing allocation or replacement, could assign duplicate memcg IDs. Offlining one group could then clean list_lru state needed by another, causing invalid later access and kernel crashes.

Likely exposure

Exposure applies to Linux kernels within the affected version ranges or downstream builds lacking the referenced backport. Systems exercising concurrent memory-cgroup creation and teardown are the clearest concern. The bundle does not establish which distribution-specific kernel packages remain vulnerable, so inventory and vendor-package verification are necessary.

Exploitation context

The CVSS vector describes a local, low-privilege, low-complexity issue requiring no user interaction, with potentially high confidentiality, integrity, and availability impact. The source reports low-frequency fleet crashes demonstrating real failure conditions, not malicious exploitation. It is not in KEV, and the supplied sources provide no evidence of active exploitation.

Researcher notes

The root cause is unsynchronized mem_cgroup_idr modification, producing missing or duplicated IDs and incorrect list_lru cleanup. Stable-kernel commits are supplied for multiple branches. The bundle contains unusual version entries and does not clearly map every introduction and fix boundary; verify branch ancestry and downstream backports before declaring a host vulnerable.

Mitigation direction

  • Install a vendor-supported kernel containing the applicable stable fix or downstream backport.
  • Prioritize shared systems where untrusted local users or workloads can exercise memory cgroups.
  • Follow distribution advisories for package-specific fixed versions and required reboot guidance.
  • Restrict unnecessary local access while patching if operationally feasible.

Validation and detection

  • Inventory running kernel versions and distribution package revisions across Linux systems.
  • Compare each package against the CVE record and applicable distribution advisory.
  • Confirm the referenced fix or an equivalent backport exists in deployed kernel sources or changelogs.
  • Check kernel logs for list_lru or memcg-related crashes; absence does not prove safety.
  • After updating and rebooting, verify systems are running the intended fixed kernel.
Prepared
Confidence
high
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
High
CVSS
7.8 (3.1)
Known Exploited
No
Published

Vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

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.

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

SSVC decision data

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

CVSS vector scores

1 official score

We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.

ScoreVersionSeverityVectorExploitImpactSource
7.8CVSS 3.1HighCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H1.85.9Linux

Vulnerability scoring details

Base CVSS 3.1 score

7.8High
CVSS 3.1 vector shape for CVE-2024-43892Attack VectorAttack ComplexityPrivileges RequiredUser InteractionScopeConfidentiality ImpactIntegrity ImpactAvailability Impact

Vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Attack Vector
NetworkAdjacentLocalPhysical
Attack Complexity
LowHigh
Privileges Required
NoneLowHigh
User Interaction
NoneRequired
Scope
ChangedUnchanged
Confidentiality Impact
HighLowNone
Integrity Impact
HighLowNone
Availability Impact
HighLowNone

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.