CVE-2026-53154
Received Received - Intake
Memory Leak in Linux Kernel HugeTLB

Publication date: 2026-06-25

Last updated on: 2026-06-25

Assigner: kernel.org

Description
In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb: restore reservation on error in hugetlb folio copy paths Two sites in mm/hugetlb.c allocate a hugetlb folio via alloc_hugetlb_folio() (consuming a VMA reservation) and then call copy_user_large_folio(), which became int-returning in commit 1cb9dc4b475c ("mm: hwpoison: support recovery from HugePage copy-on-write faults") and can now fail (e.g. -EHWPOISON on a hwpoisoned source page). On the failure path, folio_put() restores the global hugetlb pool count through free_huge_folio(), but the per-VMA reservation map entry is left marked consumed: - hugetlb_mfill_atomic_pte() resubmission path (UFFDIO_COPY) - copy_hugetlb_page_range() fork-time CoW path when hugetlb_try_dup_anon_rmap() fails (rare: pinned hugetlb anon folio under fork) User-visible effect: on UFFDIO_COPY into a private hugetlb VMA where the resubmission copy fails, the reservation for that address is leaked from the VMA's reserve map. A subsequent fault at the same address takes the no-reservation path, and under hugetlb pool pressure the task is SIGBUSed at an address it had previously reserved. The fork-time CoW path leaks the same way in the child VMA's reserve map, though it requires the much rarer combination of pinned hugetlb anon page + hwpoisoned source. Add the missing restore_reserve_on_error() call before folio_put() on both error paths.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-06-25
Last Modified
2026-06-25
Generated
2026-06-25
AI Q&A
2026-06-25
EPSS Evaluated
N/A
NVD
EUVD
Affected Vendors & Products
Showing 1 associated CPE
Vendor Product Version / Range
linux linux_kernel *
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-UNKNOWN
Attack-Flow Graph
AI Quick Actions
Instant insights powered by AI
Impact Analysis

This vulnerability can lead to a reservation leak in the huge page reservation map within a process's virtual memory area. The practical impact is that under heavy huge page pool pressure, a process may receive a SIGBUS signal unexpectedly when accessing memory it had previously reserved.

This can cause application crashes or instability, particularly in workloads that heavily use huge pages and rely on userfaultfd or fork-time copy-on-write mechanisms involving huge pages.

Executive Summary

This vulnerability exists in the Linux kernel's memory management subsystem, specifically in the handling of huge pages (hugetlb). Two code paths allocate a huge page folio and then attempt to copy user data into it using a function that can fail. When this copy operation fails, the system correctly restores the global huge page pool count but fails to restore the reservation in the per-VMA (Virtual Memory Area) reservation map. This leads to a reservation leak.

As a result, if a subsequent fault occurs at the same address, the system treats it as if there is no reservation. Under conditions where the huge page pool is under pressure, this can cause the task to receive a SIGBUS signal at an address it had previously reserved. The issue affects two specific paths: one involving userfaultfd copy operations and another involving fork-time copy-on-write with pinned huge pages.

The fix involved adding a missing call to restore the reservation on error before releasing the folio, ensuring that the reservation map is correctly updated even when the copy operation fails.

Chat Assistant
Ask questions about this CVE
Hi! I’m here to help you understand CVE-2026-53154. Ask me anything about the vulnerability, its impact, or mitigation strategies.
0/70
EPSS Chart