Linux Kernel up to 7.0.9 futex futex_wait_requeue_pi infinite loop

Summaryinfo

A vulnerability categorized as critical has been discovered in Linux Kernel up to 6.1.174/6.6.140/6.12.90/6.18.32/7.0.9. The impacted element is the function futex_wait_requeue_pi of the component futex. Executing a manipulation can lead to infinite loop. This vulnerability is tracked as CVE-2026-52977. No exploit exists. It is advisable to upgrade the affected component.

Detailsinfo

A vulnerability classified as critical was found in Linux Kernel up to 6.1.174/6.6.140/6.12.90/6.18.32/7.0.9. This vulnerability affects the function futex_wait_requeue_pi of the component futex. The manipulation with an unknown input leads to a infinite loop vulnerability. The CWE definition for the vulnerability is CWE-835. The product contains an iteration or loop with an exit condition that cannot be reached, i.e., an infinite loop. As an impact it is known to affect availability. CVE summarizes:

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().

The advisory is available at git.kernel.org. This vulnerability was named CVE-2026-52977 since 06/09/2026. The exploitation appears to be difficult. Technical details are known, but there is no available exploit.

Upgrading to version 6.1.175, 6.6.141, 6.12.91, 6.18.33 or 7.0.10 eliminates this vulnerability. Applying the patch 4e0ed44e51727d56244a822ab941efe507c47966/e3f95b1ba242e37093305812df7fdbe7288a43ac/0aacb6d18f76552e3e0ee25d9f40d21b3486f4cf/69a7cfc66405aeaa2483147653d031b3592ffc9c/0304d60abb9dcc02bc7fe6d1850f4ca206e8f1a0/bc7304f3ae20972d11db6e0b1b541c63feda5f05 is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.

If you want to get best quality of vulnerability data, you may have to visit VulDB.

Productinfo

Type

• Operating System

Vendor

• Linux

Name

• Kernel

Version

• 6.1.174
• 6.6.140
• 6.12.0
• 6.12.1
• 6.12.2
• 6.12.3
• 6.12.4
• 6.12.5
• 6.12.6
• 6.12.7
• 6.12.8
• 6.12.9
• 6.12.10
• 6.12.11
• 6.12.12
• 6.12.13
• 6.12.14
• 6.12.15
• 6.12.16
• 6.12.17
• 6.12.18
• 6.12.19
• 6.12.20
• 6.12.21
• 6.12.22
• 6.12.23
• 6.12.24
• 6.12.25
• 6.12.26
• 6.12.27
• 6.12.28
• 6.12.29
• 6.12.30
• 6.12.31
• 6.12.32
• 6.12.33
• 6.12.34
• 6.12.35
• 6.12.36
• 6.12.37
• 6.12.38
• 6.12.39
• 6.12.40
• 6.12.41
• 6.12.42
• 6.12.43
• 6.12.44
• 6.12.45
• 6.12.46
• 6.12.47
• 6.12.48
• 6.12.49
• 6.12.50
• 6.12.51
• 6.12.52
• 6.12.53
• 6.12.54
• 6.12.55
• 6.12.56
• 6.12.57
• 6.12.58
• 6.12.59
• 6.12.60
• 6.12.61
• 6.12.62
• 6.12.63
• 6.12.64
• 6.12.65
• 6.12.66
• 6.12.67
• 6.12.68
• 6.12.69
• 6.12.70
• 6.12.71
• 6.12.72
• 6.12.73
• 6.12.74
• 6.12.75
• 6.12.76
• 6.12.77
• 6.12.78
• 6.12.79
• 6.12.80
• 6.12.81
• 6.12.82
• 6.12.83
• 6.12.84
• 6.12.85
• 6.12.86
• 6.12.87
• 6.12.88
• 6.12.89
• 6.12.90
• 6.18.0
• 6.18.1
• 6.18.2
• 6.18.3
• 6.18.4
• 6.18.5
• 6.18.6
• 6.18.7
• 6.18.8
• 6.18.9
• 6.18.10
• 6.18.11
• 6.18.12
• 6.18.13
• 6.18.14
• 6.18.15
• 6.18.16
• 6.18.17
• 6.18.18
• 6.18.19
• 6.18.20
• 6.18.21
• 6.18.22
• 6.18.23
• 6.18.24
• 6.18.25
• 6.18.26
• 6.18.27
• 6.18.28
• 6.18.29
• 6.18.30
• 6.18.31
• 6.18.32
• 7.0.0
• 7.0.1
• 7.0.2
• 7.0.3
• 7.0.4
• 7.0.5
• 7.0.6
• 7.0.7
• 7.0.8
• 7.0.9

License

• open-source

Website

• Vendor: https://www.kernel.org/

CPE 2.3info

• 🔒
• 🔒
• 🔒

CPE 2.2info

• 🔒
• 🔒
• 🔒

CVSSv4info

CVSSv3info

CVSSv2info

Exploitinginfo

Threat Intelligenceinfo

Countermeasuresinfo

Timelineinfo

Sourcesinfo

Entryinfo

If you want to get best quality of vulnerability data, you may have to visit VulDB.

Discussion