CVE-2026-52977
futex: Prevent lockup in requeue-PI during signal/ timeout wakeup
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().
INFO
Published Date :
June 24, 2026, 5:17 p.m.
Last Modified :
July 14, 2026, 4:51 p.m.
Remotely Exploit :
No
Source :
416baaa9-dc9f-4396-8d5f-8c081fb06d67
CVSS Scores
| Score | Version | Severity | Vector | Exploitability Score | Impact Score | Source |
|---|---|---|---|---|---|---|
| CVSS 3.1 | MEDIUM | [email protected] |
Solution
- Remove top waiter if futex_requeue_pi_prepare fails.
- Allow waiter to remove itself in early wakeup.
- Update the Linux kernel to the latest version.
References to Advisories, Solutions, and Tools
Here, you will find a curated list of external links that provide in-depth
information, practical solutions, and valuable tools related to
CVE-2026-52977.
CWE - Common Weakness Enumeration
While CVE identifies
specific instances of vulnerabilities, CWE categorizes the common flaws or
weaknesses that can lead to vulnerabilities. CVE-2026-52977 is
associated with the following CWEs:
Common Attack Pattern Enumeration and Classification (CAPEC)
Common Attack Pattern Enumeration and Classification
(CAPEC)
stores attack patterns, which are descriptions of the common attributes and
approaches employed by adversaries to exploit the CVE-2026-52977
weaknesses.
We scan GitHub repositories to detect new proof-of-concept exploits. Following list is a collection of public exploits and proof-of-concepts, which have been published on GitHub (sorted by the most recently updated).
Results are limited to the first 15 repositories due to potential performance issues.
The following list is the news that have been mention
CVE-2026-52977 vulnerability anywhere in the article.
The following table lists the changes that have been made to the
CVE-2026-52977 vulnerability over time.
Vulnerability history details can be useful for understanding the evolution of a vulnerability, and for identifying the most recent changes that may impact the vulnerability's severity, exploitability, or other characteristics.
-
Initial Analysis by [email protected]
Jul. 14, 2026
Action Type Old Value New Value Added CVSS V3.1 AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H Added CWE NVD-CWE-noinfo Added CPE Configuration OR *cpe:2.3:o:linux:linux_kernel:7.1:rc1:*:*:*:*:*:* *cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* versions from (including) 6.2 up to (excluding) 6.6.141 *cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* versions from (including) 6.7 up to (excluding) 6.12.91 *cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* versions from (including) 6.13 up to (excluding) 6.18.33 *cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* versions from (including) 6.19 up to (excluding) 7.0.10 *cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* versions from (including) 5.15 up to (excluding) 6.1.175 Added Reference Type kernel.org: https://git.kernel.org/stable/c/0304d60abb9dcc02bc7fe6d1850f4ca206e8f1a0 Types: Patch Added Reference Type kernel.org: https://git.kernel.org/stable/c/0aacb6d18f76552e3e0ee25d9f40d21b3486f4cf Types: Patch Added Reference Type kernel.org: https://git.kernel.org/stable/c/4e0ed44e51727d56244a822ab941efe507c47966 Types: Patch Added Reference Type kernel.org: https://git.kernel.org/stable/c/69a7cfc66405aeaa2483147653d031b3592ffc9c Types: Patch Added Reference Type kernel.org: https://git.kernel.org/stable/c/bc7304f3ae20972d11db6e0b1b541c63feda5f05 Types: Patch Added Reference Type kernel.org: https://git.kernel.org/stable/c/e3f95b1ba242e37093305812df7fdbe7288a43ac Types: Patch -
New CVE Received by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
Jun. 24, 2026
Action Type Old Value New Value Added Affected [{'repo': 'https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git', 'vendor': 'Linux', 'product': 'Linux', 'versions': [{'status': 'affected', 'version': '07d91ef510fb16a2e0ca7453222105835b7ba3b8', 'lessThan': '4e0ed44e51727d56244a822ab941efe507c47966', 'versionType': 'git'}, {'status': 'affected', 'version': '07d91ef510fb16a2e0ca7453222105835b7ba3b8', 'lessThan': 'e3f95b1ba242e37093305812df7fdbe7288a43ac', 'versionType': 'git'}, {'status': 'affected', 'version': '07d91ef510fb16a2e0ca7453222105835b7ba3b8', 'lessThan': '0aacb6d18f76552e3e0ee25d9f40d21b3486f4cf', 'versionType': 'git'}, {'status': 'affected', 'version': '07d91ef510fb16a2e0ca7453222105835b7ba3b8', 'lessThan': '69a7cfc66405aeaa2483147653d031b3592ffc9c', 'versionType': 'git'}, {'status': 'affected', 'version': '07d91ef510fb16a2e0ca7453222105835b7ba3b8', 'lessThan': '0304d60abb9dcc02bc7fe6d1850f4ca206e8f1a0', 'versionType': 'git'}, {'status': 'affected', 'version': '07d91ef510fb16a2e0ca7453222105835b7ba3b8', 'lessThan': 'bc7304f3ae20972d11db6e0b1b541c63feda5f05', 'versionType': 'git'}], 'programFiles': ['kernel/futex/requeue.c'], 'defaultStatus': 'unaffected'}, {'repo': 'https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git', 'vendor': 'Linux', 'product': 'Linux', 'versions': [{'status': 'affected', 'version': '5.15'}, {'status': 'unaffected', 'version': '0', 'lessThan': '5.15', 'versionType': 'semver'}, {'status': 'unaffected', 'version': '6.1.175', 'versionType': 'semver', 'lessThanOrEqual': '6.1.*'}, {'status': 'unaffected', 'version': '6.6.141', 'versionType': 'semver', 'lessThanOrEqual': '6.6.*'}, {'status': 'unaffected', 'version': '6.12.91', 'versionType': 'semver', 'lessThanOrEqual': '6.12.*'}, {'status': 'unaffected', 'version': '6.18.33', 'versionType': 'semver', 'lessThanOrEqual': '6.18.*'}, {'status': 'unaffected', 'version': '7.0.10', 'versionType': 'semver', 'lessThanOrEqual': '7.0.*'}, {'status': 'unaffected', 'version': '7.1', 'versionType': 'original_commit_for_fix', 'lessThanOrEqual': '*'}], 'programFiles': ['kernel/futex/requeue.c'], 'defaultStatus': 'affected'}] Added 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(). Added Reference https://git.kernel.org/stable/c/0304d60abb9dcc02bc7fe6d1850f4ca206e8f1a0 Added Reference https://git.kernel.org/stable/c/0aacb6d18f76552e3e0ee25d9f40d21b3486f4cf Added Reference https://git.kernel.org/stable/c/4e0ed44e51727d56244a822ab941efe507c47966 Added Reference https://git.kernel.org/stable/c/69a7cfc66405aeaa2483147653d031b3592ffc9c Added Reference https://git.kernel.org/stable/c/bc7304f3ae20972d11db6e0b1b541c63feda5f05 Added Reference https://git.kernel.org/stable/c/e3f95b1ba242e37093305812df7fdbe7288a43ac