CVE-2026-53154: Linux Kernel Hugetlb Reservation Leak on Copy Failure

Technical summary

Two code paths in mm/hugetlb.c (hugetlb_mfill_atomic_pte and copy_hugetlb_page_range) allocate a hugetlb folio via alloc_hugetlb_folio(), which consumes a per-VMA reservation entry, then invoke copy_user_large_folio(). This function can now return errors (such as -EHWPOISON) following commit 1cb9dc4b475c. On error, the code calls folio_put() to decrement the global hugetlb pool count, but fails to call restore_reserve_on_error() to restore the per-VMA reservation map entry. This causes the reservation to remain marked consumed even though the folio was released, violating the invariant that consumed reservations correspond to allocated folios. The fix adds the missing restore_reserve_on_error() call before folio_put() on both error paths, ensuring per-VMA and global accounting remain consistent.

Business impact

This bug affects Linux systems that rely on huge pages and hugetlb memory management, particularly those using userfaultfd for live migration, snapshotting, or memory fault handling, or systems where fork of large memory processes occurs frequently. The practical impact is memory leakage from a task's perspective: reserved memory becomes unusable, and under memory pressure the task may be killed unexpectedly. For virtualization platforms, container orchestration systems, and databases using huge pages, this could manifest as unpredictable process termination or reduced effective memory availability. The risk is elevated in workloads with pinned hugetlb pages or those using memory hotplug and fault-injection testing.

Affected systems

Linux kernel versions that include commit 1cb9dc4b475c (which introduced int-returning behavior to copy_user_large_folio) and all subsequent versions are affected. The vulnerability applies to any Linux system with hugetlb enabled and active workloads using either (1) userfaultfd with UFFDIO_COPY on private hugetlb VMAs, or (2) fork of processes with pinned hugetlb anonymous pages. Systems without active hugetlb usage or without these specific workload patterns face lower practical risk.

Exploitability

This is not a vulnerability amenable to remote exploitation. It requires local access and specific conditions: either triggering a userfaultfd copy operation that fails (requiring hardware poison injection or similar fault conditions), or forking a process with pinned hugetlb pages while a copy-on-write fault occurs. Practical exploitation is difficult because hwpoisoned pages are rare in production; however, an attacker with ability to trigger page corruption or inject faults could cause denial-of-service through memory exhaustion or process termination. The CVSS score of 5.5 (Medium) reflects local-only access and high impact (availability loss) with low exploitability.

Remediation

Apply the kernel patch that adds restore_reserve_on_error() calls to both the hugetlb_mfill_atomic_pte and copy_hugetlb_page_range error paths. Consult your Linux distribution's security advisory for the specific kernel version containing the fix. As an interim mitigation, disable hugetlb functionality or restrict userfaultfd access if feasible for your workload. Monitor systems for unexpected SIGBUS crashes in memory-intensive processes as a sign of hit-after-miss reservation corruption.

Patch guidance

Obtain the patched kernel from your distribution's security updates (verify the specific kernel version from your vendor's advisory). The fix is minimal—two restore_reserve_on_error() calls inserted in hugetlb.c—so verification is straightforward. After patching, reboot to load the new kernel. For systems on stable LTS kernels, check whether your vendor has backported this fix; the issue applies to any kernel with the referenced commit. Test thoroughly in staging with workloads that exercise hugetlb and userfaultfd paths to confirm the fix resolves any observed memory reservation leaks.

Detection guidance

Monitor kernel logs for SIGBUS signals in applications using hugetlb, especially after userfaultfd operations or fork events involving large memory. Use perf or ftrace to instrument copy_user_large_folio() calls and their error returns. On vulnerable systems, write a test that triggers UFFDIO_COPY with a corrupted source page and verify that a subsequent fault at the same address does not cause unexpected SIGBUS. Memory reservation accounting can be inspected via /proc/meminfo and per-process hugetlb reservation maps under /proc/<pid>/smaps.

Why prioritize this

Medium severity with local-only exploitability warrants prompt but not emergency patching. Prioritize systems that (1) use hugetlb extensively (virtualization hosts, database servers, HPC), (2) employ userfaultfd for memory management, or (3) run long-lived processes that fork frequently. Organizations without active hugetlb workloads can deprioritize this vulnerability. Apply as part of routine security updates; do not delay other critical patching to address this issue.

Risk score, explained

CVSS 3.1 score of 5.5 reflects: Attack Vector Local (AV:L), Attack Complexity Low (AC:L), Privileges Required Low (PR:L), User Interaction None (UI:N), Scope Unchanged (S:U), with no Confidentiality or Integrity impact but high Availability impact (A:H). The score captures that an unprivileged local user can trigger conditions leading to memory exhaustion or process termination, but cannot exploit the flaw remotely or to gain unauthorized access to data.

Frequently asked questions