PT-2026-52303 · Linux · Linux
Published
2026-06-25
·
Updated
2026-06-25
·
CVE-2026-53207
None
No severity ratings or metrics are available. When they are, we'll update the corresponding info on the page.
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]
Found an issue in the description? Have something to add? Feel free to write us 👾
Related Identifiers
Affected Products
Linux