CVE-2026-53207

What it actually does

This is a Linux kernel denial-of-service flaw in the hugetlb memory-failure handling path. Two concurrent madvise(MADV_HWPOISON) operations against the same hugetlb page, racing with an unmap, can cause the kernel to enter a recursive self-deadlock on the non-recursive hugetlb_lock spinlock. The vulnerable path drops a huge-page folio reference while hugetlb_lock is still held; if that drop frees the huge folio, free_huge_folio() attempts to acquire the same lock again, resulting in an AA deadlock. The practical technical outcome is a kernel hang or severe system stall rather than data disclosure or privilege escalation.

Why it matters to the business

Successful exploitation can make affected Linux systems unresponsive, disrupting applications that depend on huge pages or exposing multi-user systems to local denial-of-service risk. The risk is most relevant where untrusted local users, containers, test workloads, or specialized applications can trigger madvise(MADV_HWPOISON) behavior and interact with hugetlb-backed memory. It is not listed in CISA KEV, has no known exploitation maturity, and has a low EPSS score, so it is generally a lower-priority emergency than remotely exploitable kernel bugs; however, kernel availability issues can still cause outages on critical compute, database, virtualization, or high-performance workloads.

How an attack unfolds

An attacker requires the ability to run code locally on an affected Linux system and reach the relevant memory-management syscall behavior. They arrange for hugetlb-backed memory to exist, then trigger concurrent madvise(MADV_HWPOISON) calls targeting the same huge page while another thread or process races an unmap of that page. Under the vulnerable interleaving, one path observes a pre-poisoned huge-page folio and exits through cleanup while hugetlb_lock is still held. The cleanup decrements the folio reference count; if the concurrent unmap has already removed the page-table reference, the reference count can reach zero and invoke huge-page free logic. That free logic tries to acquire hugetlb_lock again from the same execution context, causing a non-recursive spinlock self-deadlock and potentially hanging the kernel or affected CPU/system.

How to fix it

Apply the vendor-supplied Linux kernel update that contains the fix for the hugetlb memory-failure locking path. Because no affected product list or exact fixed versions were provided, track the fix through the relevant distribution kernel advisories and upstream stable kernel releases for the branch in use. Reboot systems into the updated kernel after patching; installing kernel packages alone is not sufficient. If immediate patching is not possible, reduce exposure by limiting local shell access, restricting untrusted workloads, tightening container privileges, disabling or limiting hugetlb usage where operationally feasible, and ensuring only trusted administrators can perform hardware-memory-poisoning test operations. Treat mitigations as risk reduction only, not a substitute for the kernel fix.

How to confirm the fix worked

Confirm systems are running a kernel build that includes the upstream fix moving hugetlb_lock handling so folio_put() is performed outside the lock in the MADV_HWPOISON hugetlb path. Validate the active kernel with uname -a and compare the package version against the Linux distribution’s advisory or fixed kernel package. Ensure systems have been rebooted into the patched kernel by comparing installed kernel packages with the running kernel. Where safe and appropriate in a non-production test environment, reproduce the concurrent MADV_HWPOISON/unmap stress pattern against hugetlb pages before and after patching to confirm the deadlock no longer occurs. Also verify that hugetlb and memory-failure related kernel self-tests or regression tests pass on patched builds.

Typical attack path

1. Obtain local code execution on an affected Linux host, container host, or multi-user system.
2. Allocate or identify memory backed by hugetlb/huge pages.
3. Use multiple threads or processes to issue madvise(MADV_HWPOISON) against the same hugetlb page.
4. Race those calls with an unmap operation on the same page mapping.
5. Trigger the vulnerable cleanup path where folio_put() occurs while hugetlb_lock is held.
6. Cause free_huge_folio() to re-acquire hugetlb_lock recursively, resulting in a kernel deadlock and denial of service.

How to detect it

Detection is primarily behavioral because exploitation causes kernel-level locking failure rather than leaving a unique file, process, or network artifact. Review kernel logs, persistent journal logs, console logs, crash dumps, and hypervisor or out-of-band management events for hangs, watchdog alerts, soft lockups, hard lockups, RCU stalls, or hugetlb/memory-failure activity around the time of an outage. Useful sources include dmesg, /var/log/kern.log, /var/log/messages, journalctl -k, pstore/ramoops, kdump/vmcore analysis, and monitoring alerts for node unresponsiveness. Look for suspicious local processes running memory-management fuzzers, stress tools, or custom programs using madvise with MADV_HWPOISON and huge pages. If auditd or eBPF syscall tracing is available, search for unusual madvise syscall activity combined with huge-page mappings and munmap/unmap activity from the same user or process group. In crash dump analysis, inspect blocked CPUs or stack traces for hugetlb_lock, get_huge_page_for_hwpoison, __get_huge_page_for_hwpoison, folio_put, free_huge_folio, memory_failure, and madvise-related call paths.

• MADV_HWPOISON
• hugetlb_lock
• get_huge_page_for_hwpoison
• __get_huge_page_for_hwpoison
• try_memory_failure_hugetlb
• hugetlb_update_hwpoison
• MF_HUGETLB_FOLIO_PRE_POISONED
• free_huge_folio
• memory_failure
• madvise
• soft lockup
• hard lockup
• watchdog: BUG: soft lockup
• rcu: INFO: rcu_sched detected stalls
• NMI watchdog: Watchdog detected hard LOCKUP
• /var/log/kern.log
• /var/log/messages
• journalctl -k
• /sys/kernel/mm/hugepages
• /proc/sys/vm/nr_hugepages

What your security team should do

• Inventory Linux systems that enable or rely on hugetlb/huge pages, especially shared compute, container hosts, virtualization nodes, database servers, and HPC systems.
• Prioritize patching systems that allow untrusted local users, CI jobs, containers, or third-party workloads to execute code.
• Apply the appropriate vendor kernel update and reboot into the fixed kernel.
• Until patching is complete, restrict local access and reduce privileges for workloads that can manipulate huge-page mappings or run memory-management stress tools.
• Monitor for kernel hangs, soft lockups, RCU stalls, watchdog events, and hugetlb/memory-failure messages that could indicate attempted triggering or instability.
• Track vendor advisories because fixed versions vary by distribution and kernel branch.
• Do not treat the low EPSS score or absence from KEV as proof of no risk; local denial-of-service flaws can still materially affect high-availability systems.