CVE-2024-49964 in Linux
Summary
by MITRE • 10/21/2024
In the Linux kernel, the following vulnerability has been resolved:
mm/hugetlb: fix memfd_pin_folios free_huge_pages leak
memfd_pin_folios followed by unpin_folios fails to restore free_huge_pages if the pages were not already faulted in, because the folio refcount for pages created by memfd_alloc_folio never goes to 0. memfd_pin_folios needs another folio_put to undo the folio_try_get below:
memfd_alloc_folio() alloc_hugetlb_folio_nodemask() dequeue_hugetlb_folio_nodemask() dequeue_hugetlb_folio_node_exact() folio_ref_unfreeze(folio, 1); ; adds 1 refcount folio_try_get() ; adds 1 refcount hugetlb_add_to_page_cache() ; adds 512 refcount (on x86)
With the fix, after memfd_pin_folios + unpin_folios, the refcount for the (unfaulted) page is 512, which is correct, as the refcount for a faulted unpinned page is 513.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 03/21/2026
The vulnerability described in CVE-2024-49964 represents a critical memory management flaw within the Linux kernel's huge page handling subsystem. This issue specifically affects the hugetlb (huge page) implementation where memory management operations involving memfd (memory file descriptor) backed pages fail to properly release memory resources. The problem manifests when a sequence of operations involving memfd_pin_folios followed by unpin_folios does not correctly restore the free_huge_pages counter, leading to a memory leak scenario that can accumulate over time and potentially exhaust system resources.
The technical root cause stems from improper reference counting management within the huge page allocation and deallocation process. When memfd_alloc_folio is invoked, it performs a series of operations that increment the folio reference count through multiple layers including dequeue_hugetlb_folio_nodemask which adds one reference, followed by folio_try_get which adds another reference, and finally hugetlb_add_to_page_cache which adds 512 references on x86 architectures. The vulnerability occurs because the memfd_pin_folios function fails to properly account for all these reference increments when subsequently calling unpin_folios, leaving pages in a state where their reference count never reaches zero even after being unpinned.
This memory leak directly impacts system stability and resource utilization by preventing proper cleanup of huge page resources that should be returned to the free_huge_pages pool. The operational impact extends beyond simple resource exhaustion as it can lead to system performance degradation, potential denial of service conditions, and unpredictable memory allocation behavior in applications relying on huge page memory management. The issue is particularly concerning because it affects pages that were never faulted in, meaning the leak occurs even for pages that have not been accessed or mapped into virtual memory space, making it difficult to detect and predict.
The fix implemented addresses this by ensuring that memfd_pin_folios properly accounts for all reference count increments that occurred during page allocation, requiring an additional folio_put operation to balance the folio_try_get call that was made during the allocation process. This aligns with standard kernel memory management practices and follows established patterns for reference counting in the Linux kernel's memory subsystem. The vulnerability demonstrates the complexity of managing reference counts in high-performance memory management systems and highlights the importance of careful accounting in kernel-level operations. Security implications include potential resource exhaustion attacks that could be exploited to cause system instability or denial of service conditions, particularly in environments with high memory allocation activity. The issue relates to CWE-401 (Improper Release of Memory) and could be categorized under ATT&CK technique T1499.001 (Endpoint Denial of Service) when exploited in a malicious context.