CVE-2026-53154

What it actually does

This is a Linux kernel HugeTLB memory-management flaw in error handling for hugetlb folio copy paths. When a huge page is allocated for a reserved private HugeTLB VMA and a subsequent large-folio copy fails, the kernel returns the huge page to the global pool but fails to restore the per-VMA reservation entry. The reservation map can therefore incorrectly show that a reservation was consumed even though the allocation did not complete. A later fault at the same virtual address may proceed as if no reservation exists and, when the HugeTLB pool is under pressure, the affected task can receive SIGBUS. The practical impact is local denial of service against processes using private HugeTLB mappings, especially through the UFFDIO_COPY resubmission path; a fork-time copy-on-write variant exists but requires rarer conditions involving pinned anonymous HugeTLB pages and a poisoned source page.

Why it matters to the business

The main risk is instability or termination of workloads that rely on HugeTLB pages, such as high-performance databases, virtualization components, in-memory analytics, latency-sensitive services, or specialized memory-intensive applications. Exploitation requires local capability to exercise the relevant memory paths and unusual failure conditions, and the CVE is not in CISA KEV, not associated with ransomware, and has very low EPSS, so broad internet-scale exploitation is unlikely. However, organizations running multi-tenant Linux systems or workloads that expose userfaultfd/HugeTLB behavior to untrusted local users should treat it as a reliability and tenant-isolation concern.

How an attack unfolds

An attacker or fault-inducing local workload first obtains code execution as an unprivileged or otherwise constrained local user on a Linux system where HugeTLB pages and the relevant memory-management features are available. The attacker creates or targets a private HugeTLB VMA with a reservation and then drives a copy path that allocates a HugeTLB folio and calls the large-folio copy routine. In the more reachable path, this involves userfaultfd and UFFDIO_COPY into a private HugeTLB mapping. If the copy operation fails, for example because the source page is hardware-poisoned or an equivalent error path is reached, the kernel frees the allocated folio but does not restore the VMA reservation. The attacker then causes a subsequent page fault at the same address while the HugeTLB pool is constrained. Because the reservation state is now inconsistent, the task may be delivered SIGBUS despite having previously reserved that address. The result is denial of service of the affected process rather than code execution or privilege escalation.

How to fix it

Apply a Linux kernel update from the operating system or kernel vendor that includes the fix for the HugeTLB reservation restoration error in mm/hugetlb.c. No product-specific fixed versions were provided, so remediation should be tracked through the relevant distribution advisories and kernel stable updates. Where immediate patching is not possible, reduce exposure by limiting HugeTLB use to trusted workloads, minimizing configured HugeTLB pool availability for untrusted users, and restricting userfaultfd where operationally feasible. On Linux systems that support it, consider setting vm.unprivileged_userfaultfd=0 to prevent unprivileged userfaultfd use, while validating application compatibility. Also review container, sandbox, and multi-tenant configurations to ensure untrusted workloads cannot freely allocate or manipulate HugeTLB mappings.

How to confirm the fix worked

Confirm that the running kernel package includes the vendor fix for this CVE or contains the upstream change that restores the reservation on HugeTLB copy failure paths. Validate the actual booted kernel, not only the installed package, using standard platform inventory and kernel version checks. Review whether HugeTLB pages are configured by checking huge page pool settings and whether unprivileged userfaultfd is enabled. In a non-production test environment, validation can include exercising private HugeTLB mappings with userfaultfd error handling and confirming that reservations are restored correctly after failed copy operations and that later faults do not unexpectedly SIGBUS under HugeTLB pressure. Avoid attempting fault-injection or hardware-poison testing on production systems.

Typical attack path

1. Gain local execution on a Linux host that supports HugeTLB pages and permits use of the relevant memory APIs.
2. Create or interact with a private HugeTLB-backed mapping that has an address reservation.
3. Trigger a HugeTLB folio copy path, most notably UFFDIO_COPY via userfaultfd, or the rarer fork-time copy-on-write path with pinned anonymous HugeTLB pages.
4. Cause or wait for the copy operation to fail, such as through a hardware-poisoned source page or equivalent kernel error path.
5. Exhaust or pressure the HugeTLB pool so later allocation depends on correct reservation accounting.
6. Fault the same address again, causing the process to receive SIGBUS due to the leaked reservation state.
7. Use the resulting crash or service interruption as a local denial-of-service condition.

How to detect it

There is no unique network indicator or single log string that proves exploitation, because this is a local kernel memory-accounting flaw that manifests as process crashes. Detection should focus on host telemetry. Review kernel logs, system journals, application crash logs, core-dump records, and EDR telemetry for SIGBUS events affecting applications that use HugeTLB pages. Correlate those crashes with evidence of HugeTLB pool pressure, userfaultfd activity, UFFDIO_COPY-related errors, memory hardware-poison events, or memory-failure messages. On Linux hosts, useful sources include dmesg, journald, /var/log/kern.log, /var/log/messages, auditd syscall records if userfaultfd/ioctl monitoring is enabled, coredumpctl/systemd-coredump metadata, and application supervisor logs. Because hardware-poison and HugeTLB allocation failures can also occur naturally, detection should look for repeated or suspiciously timed crashes by local users or workloads rather than relying on one artifact.

• SIGBUS
• BUS_ADRERR
• userfaultfd
• UFFDIO_COPY
• hugetlb
• HugeTLB
• hugepages
• Memory failure
• hwpoison
• hardware memory corruption
• systemd-coredump
• Process * dumped core

What your security team should do

• Prioritize patching Linux kernels on multi-tenant systems, systems that allow untrusted local code execution, and hosts running HugeTLB-heavy workloads.
• Track vendor advisories for the exact kernel package containing the fix, since no fixed versions were supplied in the input.
• Inventory systems with configured HugeTLB pools and systems where unprivileged userfaultfd is enabled.
• Where compatible, disable unprivileged userfaultfd using vm.unprivileged_userfaultfd=0 to reduce reachable attack surface.
• Restrict HugeTLB allocation and related capabilities to trusted workloads, users, containers, and service accounts.
• Monitor for unexplained SIGBUS crashes in HugeTLB-backed applications, especially when accompanied by hardware memory-poison or HugeTLB allocation-pressure messages.
• Treat exploitation likelihood as low given very low EPSS, no known exploit maturity, and no KEV listing, but remediate during normal kernel maintenance windows for reliability.