CVE-2026-53207: mm/memory-failure: fix hugetlb_lock AA deadlock in get_huge_page_for_hwpoison

In the Linux kernel, the following vulnerability has been resolved:

mm/memory-failure: fix hugetlblock AA deadlock in gethugepageforhwpoison

Two concurrent madvise(MADVHWPOISON) calls on the same hugetlb page can trigger a recursive spinlock self-deadlock (AA deadlock) on hugetlblock when racing with a concurrent unmap:

thread#0 thread#1 -------- -------- madvise(folio, MADVHWPOISON) -> poisons the folio successfully madvise(folio, MADVHWPOISON) unmap(folio) trymemoryfailurehugetlb gethugepageforhwpoison spinlockirq(&hugetlblock) <- held gethugepageforhwpoison hugetlbupdatehwpoison() -> MFHUGETLBFOLIOPREPOISONED goto out: folioput() refcount: 1 -> 0 freehugefolio() spinlockirqsave(&hugetlblock) -> AA DEADLOCK!

The out: path in gethugepageforhwpoison() calls folioput() to drop the GUP reference while the hugetlblock is still held by the hugetlb.c wrapper gethugepageforhwpoison(). If concurrent unmap has released the page table mapping reference, folioput() drops the folio refcount to zero, triggering freehugefolio() which attempts to re-acquire the non-recursive hugetlblock.

Fix this by moving hugetlblock acquisition from the hugetlb.c wrapper into gethugepageforhwpoison(). Place spinunlockirq() before the folioput() at the out: label so the folio is always released outside the lock.

[akpm@linux-foundation.org: fix race, rename label per Miaohe]