CVE-2026-53207

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/memory-failure: fix hugetlb_lock AA deadlock in get_huge_page_for_hwpoison<br /> <br /> Two concurrent madvise(MADV_HWPOISON) calls on the same hugetlb page can<br /> trigger a recursive spinlock self-deadlock (AA deadlock) on hugetlb_lock<br /> when racing with a concurrent unmap:<br /> <br /> thread#0 thread#1<br /> -------- --------<br /> madvise(folio, MADV_HWPOISON)<br /> -&gt; poisons the folio successfully<br /> madvise(folio, MADV_HWPOISON) unmap(folio)<br /> try_memory_failure_hugetlb<br /> get_huge_page_for_hwpoison<br /> spin_lock_irq(&amp;hugetlb_lock) MF_HUGETLB_FOLIO_PRE_POISONED<br /> goto out:<br /> folio_put()<br /> refcount: 1 -&gt; 0<br /> free_huge_folio()<br /> spin_lock_irqsave(&amp;hugetlb_lock)<br /> -&gt; AA DEADLOCK!<br /> <br /> The out: path in __get_huge_page_for_hwpoison() calls folio_put() to drop<br /> the GUP reference while the hugetlb_lock is still held by the hugetlb.c<br /> wrapper get_huge_page_for_hwpoison(). If concurrent unmap has released<br /> the page table mapping reference, folio_put() drops the folio refcount to<br /> zero, triggering free_huge_folio() which attempts to re-acquire the<br /> non-recursive hugetlb_lock.<br /> <br /> Fix this by moving hugetlb_lock acquisition from the hugetlb.c wrapper<br /> into get_huge_page_for_hwpoison(). Place spin_unlock_irq() before the<br /> folio_put() at the out: label so the folio is always released outside the<br /> lock.<br /> <br /> [akpm@linux-foundation.org: fix race, rename label per Miaohe]