CVE-2026-53207
Received Received - Intake
Deadlock in Linux Kernel HugeTLB Memory Handling

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/memory-failure: fix hugetlb_lock AA deadlock in get_huge_page_for_hwpoison Two concurrent madvise(MADV_HWPOISON) calls on the same hugetlb page can trigger a recursive spinlock self-deadlock (AA deadlock) on hugetlb_lock when racing with a concurrent unmap: thread#0 thread#1 -------- -------- madvise(folio, MADV_HWPOISON) -> poisons the folio successfully madvise(folio, MADV_HWPOISON) unmap(folio) try_memory_failure_hugetlb get_huge_page_for_hwpoison spin_lock_irq(&hugetlb_lock) <- held __get_huge_page_for_hwpoison hugetlb_update_hwpoison() -> MF_HUGETLB_FOLIO_PRE_POISONED goto out: folio_put() refcount: 1 -> 0 free_huge_folio() spin_lock_irqsave(&hugetlb_lock) -> AA DEADLOCK! The out: path in __get_huge_page_for_hwpoison() calls folio_put() to drop the GUP reference while the hugetlb_lock is still held by the hugetlb.c wrapper get_huge_page_for_hwpoison(). If concurrent unmap has released the page table mapping reference, folio_put() drops the folio refcount to zero, triggering free_huge_folio() which attempts to re-acquire the non-recursive hugetlb_lock. Fix this by moving hugetlb_lock acquisition from the hugetlb.c wrapper into get_huge_page_for_hwpoison(). Place spin_unlock_irq() before the folio_put() at the out: label so the folio is always released outside the lock. [[email protected]: fix race, rename label per Miaohe]
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
CVE-2026-53207
EUVD
EUVD-2026-39298
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
Executive Summary

This vulnerability exists in the Linux kernel's memory management subsystem, specifically related to handling huge pages (hugetlb). It involves a deadlock condition triggered when two concurrent madvise(MADV_HWPOISON) calls are made on the same huge page while racing with a concurrent unmap operation.

The issue arises because the code holds a spinlock (hugetlb_lock) while calling folio_put(), which can lead to a recursive spinlock deadlock (AA deadlock) if folio_put() triggers free_huge_folio() that tries to re-acquire the same non-recursive spinlock.

The fix involved moving the acquisition of the hugetlb_lock into the get_huge_page_for_hwpoison() function and ensuring the spinlock is released before calling folio_put(), preventing the deadlock.

Impact Analysis

This vulnerability can cause a deadlock in the Linux kernel when handling huge pages under certain concurrent operations. Such a deadlock can lead to system hangs or degraded performance as kernel threads wait indefinitely for a lock to be released.

In practical terms, this could affect system stability and reliability, especially on systems that heavily use huge pages and memory poisoning features for error detection or management.

Mitigation Strategies

The vulnerability is fixed by a patch in the Linux kernel that changes the locking behavior in the hugetlb memory failure handling code.

To mitigate this vulnerability immediately, you should update your Linux kernel to a version that includes the fix for this issue.

The fix involves moving the hugetlb_lock acquisition inside get_huge_page_for_hwpoison() and releasing the lock before dropping the folio reference, preventing the deadlock.

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