CVE-2026-53207: Linux Kernel hugetlb_lock Deadlock in Hardware Poison Handling

Technical summary

The vulnerability arises from a recursive spinlock acquisition (AA deadlock) on hugetlb_lock in the memory failure path. The issue occurs when get_huge_page_for_hwpoison() acquires hugetlb_lock at the wrapper level, then calls __get_huge_page_for_hwpoison() which handles the poisoned folio case (MF_HUGETLB_FOLIO_PRE_POISONED). When the out: path executes folio_put() to release the GUP reference while hugetlb_lock is still held, and the concurrent unmap has already dropped the page table reference, the folio refcount reaches zero, triggering free_huge_folio(). This function attempts to re-acquire the non-recursive hugetlb_lock, causing a deadlock. The fix relocates spin_lock_irq acquisition into get_huge_page_for_hwpoison() and moves spin_unlock_irq() before folio_put() to ensure the lock is released before any potential refcount-driven cleanup.

Business impact

This vulnerability enables a local denial of service attack. A user with standard privileges can cause the kernel to deadlock, freezing the system or making it unresponsive. On multi-tenant systems or shared servers, this could disrupt other users' workloads. The impact is limited to availability; no data corruption or privilege escalation is possible.

Affected systems

The Linux kernel is affected across multiple stable branches and distributions that include hugetlb memory failure handling code. The vulnerability requires a kernel compiled with huge page support (CONFIG_HUGETLB_PAGE). Systems without huge page support or those not exposing madvise(MADV_HWPOISON) to unprivileged users face reduced practical risk.

Exploitability

Exploitability is straightforward from a code perspective: two concurrent madvise() calls with MADV_HWPOISON on the same huge page while an unmap occurs in another thread can reliably trigger the deadlock. However, this requires local system access and knowledge of huge page allocation patterns. The vulnerability is not remotely exploitable and does not require elevated privileges. The race condition window is tight but deterministic under lab conditions, though reproducing it in production may require specific system load and timing conditions.

Remediation

The kernel fix involves refactoring the locking strategy in the memory failure code. The hugetlb_lock acquisition and release must be moved to ensure the lock is never held when folio_put() is called, preventing the recursive acquisition that triggers the deadlock. Verify the patch against your Linux distribution's official kernel advisory and apply updates as released by your vendor.

Patch guidance

Monitor your Linux vendor's security advisory channels and kernel update announcements for patches addressing this CVE. When patches become available, prioritize systems that (1) are configured with huge page support, (2) allow unprivileged madvise() calls, or (3) run memory-intensive workloads on shared systems. Test patches in a non-production environment first to ensure compatibility with your specific kernel configuration and workloads.

Detection guidance

System-level detection relies on identifying the conditions that trigger the bug: concurrent madvise(MADV_HWPOISON) calls on the same huge page combined with concurrent page unmapping. Monitor kernel logs for spinlock timeout warnings or hung task warnings mentioning hugetlb_lock. Use perf or other profiling tools to detect unexpected kernel spinlock contention on hugetlb_lock. A hung kernel process attempting to acquire hugetlb_lock while already holding it would appear as a process in 'D' state in ps output, though this indicates an active exploit attempt rather than benign activity.

Why prioritize this

While this is a medium-severity local denial of service, prioritization should account for your deployment model. Large shared systems, HPC clusters, and multi-tenant environments where huge pages are in active use should treat this as higher priority. Single-user systems or those without huge page workloads can defer patching. The lack of remote exploitability and privilege escalation potential makes this lower urgency than critical kernel bugs, but the ease of triggering a complete system hang justifies timely patching.

Risk score, explained

CVSS 3.1 score of 5.5 (Medium) reflects the vulnerability's local-only attack vector, low privilege requirement, and complete availability impact with no confidentiality or integrity compromise. The score correctly captures that while system-level damage is severe (system becomes unresponsive), the attack scope is limited to the local system and requires non-standard system calls and conditions.

Frequently asked questions