CVE-2026-53207

Analyzed Analyzed - Analysis Complete

Deadlock in Linux Kernel HugeTLB Memory Handling

Publication date: 2026-06-25

Last updated on: 2026-07-02

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-07-02

Generated

2026-07-15

AI Q&A

2026-06-25

EPSS Evaluated

2026-07-14

NVD

CVE-2026-53207

EUVD

EUVD-2026-39298

Affected Vendors & Products

Vendor	Product	Version / Range
linux	linux_kernel	5.18
linux	linux_kernel	5.18
linux	linux_kernel	5.18
linux	linux_kernel	5.18
linux	linux_kernel	5.18
linux	linux_kernel	7.1
linux	linux_kernel	7.1
linux	linux_kernel	7.1
linux	linux_kernel	7.1
linux	linux_kernel	From 5.15.54 (inc) to 5.16 (exc)
linux	linux_kernel	From 6.2 (inc) to 6.6.143 (exc)
linux	linux_kernel	From 6.13 (inc) to 6.18.36 (exc)
linux	linux_kernel	From 6.7 (inc) to 6.12.94 (exc)
linux	linux_kernel	From 6.19 (inc) to 7.0.13 (exc)
linux	linux_kernel	7.1
linux	linux_kernel	7.1
linux	linux_kernel	From 5.18.1 (inc) to 6.1.176 (exc)

Helpful Resources

Exploitability

CWE

KEV

CWE ID	Description
CWE-667	The product does not properly acquire or release a lock on a resource, leading to unexpected resource state changes and behaviors.

Attack-Flow Graph

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.

Hi! I’m here to help you understand CVE-2026-53207. Ask me anything about the vulnerability, its impact, or mitigation strategies.

0/70