CVE-2024-36000: mm/hugetlb: fix missing hugetlb_lock for resv uncharge
In the Linux kernel, the following vulnerability has been resolved:
mm/hugetlb: fix missing hugetlb_lock for resv uncharge
There is a recent report on UFFDIO_COPY over hugetlb:
https://lore.kernel.org/all/000000000000ee06de0616177560@google.com/
350: lockdep_assert_held(&hugetlb_lock);
Should be an issue in hugetlb but triggered in an userfault context, where
it goes into the unlikely path where two threads modifying the resv map
together. Mike has a fix in that path for resv uncharge but it looks like
the locking criteria was overlooked: hugetlb_cgroup_uncharge_folio_rsvd()
will update the cgroup pointer, so it requires to be called with the lock
held.
Security readout for executives and security teams
Plain-English summary
CVE-2024-36000 is a Linux kernel bug in huge page memory accounting. The source describes a missing lock when reserved huge-page cgroup state is changed. Business impact is unclear because no CVSS score, impact statement, or exploitation report is provided.
Executive priority
Treat as a kernel maintenance item until more impact evidence appears. It deserves timely patching on shared or multi-tenant Linux systems, but the provided sources do not justify emergency response or active-exploitation claims.
Technical view
The bug is in mm/hugetlb reservation uncharge handling. During UFFDIO_COPY over hugetlb, an uncommon race can occur when two threads modify the reservation map. hugetlb_cgroup_uncharge_folio_rsvd() updates a cgroup pointer and must run under hugetlb_lock; the fix adds the missing locking discipline.
Likely exposure
Exposure appears limited to Linux kernels in the affected ranges that use hugetlb and the related userfaultfd/cgroup path. The bundle lists Linux 5.10, 6.1.91, 6.6.30, 6.8.9, and 6.9 as affected entries, but version-range details are incomplete.
Exploitation context
The source cites a report triggered through UFFDIO_COPY over hugetlb. It does not state public exploitation, a proof of concept, remote reachability, privilege requirements, or real-world abuse. KEV status is false.
Researcher notes
The core issue is a locking omission around reserved hugetlb cgroup uncharge state. The interesting validation point is whether deployed kernels include the stable commits, because downstream vendors may backport without changing major kernel versions.
Mitigation direction
Review Linux distributor advisories for CVE-2024-36000.
Apply kernel updates containing the referenced stable fixes.
Prioritize hosts running untrusted local workloads or hugetlb-heavy services.
Check vendor guidance before changing userfaultfd or huge-page settings.
Validation and detection
Inventory Linux kernel versions across servers and containers hosts.
Identify systems using hugetlb, huge pages, cgroups, or userfaultfd-dependent workloads.
Confirm whether the referenced stable commits are present in deployed kernels.
Track distribution-specific backport status for CVE-2024-36000.
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-36000 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
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.