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.

[akpm@linux-foundation.org: fix race, rename label per Miaohe]
Published: 2026-06-25
Score: n/a
EPSS: n/a
KEV: No
Impact: n/a
Action: n/a
AI Analysis

Impact

This kernel bug allows two concurrent madvise(MADV_HWPOISON) calls on the same hugetlb page to trigger a recursive spinlock self-deadlock on hugetlb_lock when a concurrent unmap races. The deadlock stalls the kernel and can disrupt service availability, but it does not directly enable code execution or confidentiality compromise. The vulnerability arises from improper lock ordering in get_huge_page_for_hwpoison and results in a self-deadlock that can affect all processes sharing the page.

Affected Systems

All Linux kernel releases that include the pre-fix code path are affected, as the CPE list indicates the entire Linux kernel and no specific version range is provided. The vulnerability exists in the mainline kernel source before the commit that fixed the lock acquisition logic. Users of any distribution using kernels older than the latest patch are potentially exposed.

Risk and Exploitability

The CVSS score is not provided and the EPSS score is unavailable, but the vulnerability is not listed in the CISA KEV catalog. Because the flaw requires privileged kernel access to trigger madvise(MADV_HWPOISON) and unmap operations, the most likely attack vector is local or requires root privileges. An attacker with sufficient permissions could cause a kernel hang that may lead to service disruption, but the vulnerability does not provide a direct path for remote code execution or data exfiltration. The lack of public exploitation evidence suggests a lower exploitation probability, though the impact on availability is significant if exploited.

Generated by OpenCVE AI on June 25, 2026 at 11:27 UTC.

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Apply the latest security update for the Linux kernel that incorporates the fix for CVE-2026-53207.
  • Restrict or disable components that invoke madvise(MADV_HWPOISON) and hugetlb page unmap operations in your environment until the patch is applied.
  • If an update is not immediately possible, avoid using hugetlb memory allocations that may be triggered by madvise(MADV_HWPOISON) in high-privilege workloads.

Generated by OpenCVE AI on June 25, 2026 at 11:27 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Thu, 25 Jun 2026 11:45:00 +0000

Type Values Removed Values Added
Weaknesses CWE-667

Thu, 25 Jun 2026 09:15:00 +0000

Type Values Removed Values Added
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. [akpm@linux-foundation.org: fix race, rename label per Miaohe]
Title mm/memory-failure: fix hugetlb_lock AA deadlock in get_huge_page_for_hwpoison
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-06-25T08:39:13.592Z

Reserved: 2026-06-09T07:44:35.391Z

Link: CVE-2026-53207

cve-icon Vulnrichment

No data.

cve-icon NVD

No data.

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-06-25T11:30:06Z

Weaknesses