CVE-2026-52977
Received Received - Intake
Futex Lockup in Linux Kernel via Requeue-PI Race Condition

Publication date: 2026-06-24

Last updated on: 2026-06-24

Assigner: kernel.org

Description
In the Linux kernel, the following vulnerability has been resolved: futex: Prevent lockup in requeue-PI during signal/ timeout wakeup During wait-requeue-pi (task A) and requeue-PI (task B) the following race can happen: Task A Task B futex_wait_requeue_pi() futex_setup_timer() futex_do_wait() futex_requeue() CLASS(hb, hb1)(&key1); CLASS(hb, hb2)(&key2); *timeout* futex_requeue_pi_wakeup_sync() requeue_state = Q_REQUEUE_PI_IGNORE *blocks on hb->lock* futex_proxy_trylock_atomic() futex_requeue_pi_prepare() Q_REQUEUE_PI_IGNORE => -EAGAIN double_unlock_hb(hb1, hb2) *retry* Task B acquires both hb locks and attempts to acquire the PI-lock of the top most waiter (task B). Task A is leaving early due to a signal/ timeout and started removing itself from the queue. It updates its requeue_state but can not remove it from the list because this requires the hb lock which is owned by task B. Usually task A is able to swoop the lock after task B unlocked it. However if task B is of higher priority then task A may not be able to wake up in time and acquire the lock before task B gets it again. Especially on a UP system where A is never scheduled. As a result task A blocks on the lock and task B busy loops, trying to make progress but live locks the system instead. Tragic. This can be fixed by removing the top most waiter from the list in this case. This allows task B to grab the next top waiter (if any) in the next iteration and make progress. Remove the top most waiter if futex_requeue_pi_prepare() fails. Let the waiter conditionally remove itself from the list in handle_early_requeue_pi_wakeup().
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-06-24
Last Modified
2026-06-24
Generated
2026-06-25
AI Q&A
2026-06-24
EPSS Evaluated
N/A
NVD
EUVD
Affected Vendors & Products
Showing 1 associated CPE
Vendor Product Version / Range
linux linux_kernel *
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-UNKNOWN
Attack-Flow Graph
AI Quick Actions
Instant insights powered by AI
Executive Summary

This vulnerability occurs in the Linux kernel's futex subsystem, specifically during the requeue-PI operation involving two tasks (Task A and Task B). A race condition can happen when Task A is waiting and tries to remove itself from a queue due to a signal or timeout, but cannot acquire a lock because Task B holds it. If Task B has higher priority, Task A may never get scheduled to acquire the lock, causing Task A to block and Task B to busy loop, resulting in a live lock that can freeze the system.

The issue is fixed by removing the top most waiter from the list if the preparation to requeue fails, allowing Task B to proceed with the next waiter and avoid the live lock.

Impact Analysis

This vulnerability can cause a live lock in the Linux kernel futex subsystem, which may lead to system lockup or unresponsiveness. Specifically, it can cause certain tasks to block indefinitely while others busy loop, potentially freezing the system or severely degrading performance.

Mitigation Strategies

The vulnerability is resolved by a fix in the Linux kernel that prevents lockup in futex requeue-PI during signal or timeout wakeup. To mitigate this vulnerability immediately, you should update your Linux kernel to a version that includes this fix.

Specifically, the fix involves removing the top most waiter if futex_requeue_pi_prepare() fails and allowing the waiter to conditionally remove itself from the list in handle_early_requeue_pi_wakeup().

Therefore, applying the latest kernel patches or upgrading to a kernel version released after 2026-06-24 that contains this fix is the recommended immediate step.

Chat Assistant
Ask questions about this CVE
Hi! I’m here to help you understand CVE-2026-52977. Ask me anything about the vulnerability, its impact, or mitigation strategies.
0/70
EPSS Chart