CVE-2026-53207

What the bug is

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]

Where it lives

The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.

include/linux/hugetlb.h
include/linux/mm.h
mm/hugetlb.c
mm/memory-failure.c

What this is

HUGETLB SUBSYSTEMMAINTAINERS section matched on include/linux/hugetlb.h · linux-mm@kvack.org · Maintained

Check it on the machine

grep -w CONFIG_HUGETLBFS /boot/config-$(uname -r)

Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.

Show whether Debian builds this, per release

Debian builds this, but not on every flavour. At least one release below builds the code on some of its kernel flavours and not on others, so the answer depends on the architecture and flavour installed.

• bookwormYnot built on armhf/armmp, armhf/rt/armmp
• trixieYnot built on armel/rpi, armhf/armmp, armhf/rt/armmp
• forky, sidYnot built on armhf/armmp

Y

built in where it is built at all; some flavours do not build it

Build switch

CONFIG_HUGETLBFS

From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages

Signals

Published

2026-06-25 (4 months ago)source

CVSS

no vector published, unrated

Attack vector

not published

EPSS

0.10%, higher than 0.6% of all CVEssource

CISA KEV

not listedthe KEV catalogue

Debian urgency

not yet assignedsource

Subsystem

include/linux

Upstream fixes

The versions the CNA records as introducing and fixing this, and the commit for each. source

Introduced	Fixed in	Commit
5.18	6.1.176	fc3ff42cb0cb
5.18	6.6.143	77b73b54801a
5.18	6.12.94	a33bfed648c1
5.18	6.18.36	dd77a83915b0
5.18	7.0.13	bf7ba8f96c25
5.18	7.1	3c2d42b8ee34
5.15.54	0	0

Debian advisories