CVE-2026-52977

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

• https://git.kernel.org/stable/c/0304d60abb9dcc02bc7fe6d1850f4ca206e8f1a0Patch
• https://git.kernel.org/stable/c/0aacb6d18f76552e3e0ee25d9f40d21b3486f4cfPatch
• https://git.kernel.org/stable/c/4e0ed44e51727d56244a822ab941efe507c47966Patch
• https://git.kernel.org/stable/c/69a7cfc66405aeaa2483147653d031b3592ffc9cPatch
• https://git.kernel.org/stable/c/bc7304f3ae20972d11db6e0b1b541c63feda5f05Patch
• https://git.kernel.org/stable/c/e3f95b1ba242e37093305812df7fdbe7288a43acPatch

Published

Jun 24, 2026

Last Modified

Jul 14, 2026

Status

Analyzed

• How Strix found a critical auth bypass in etcdStrix autonomously discovered a critical authentication bypass in etcd, later designated CVE-2026-33413.
• Autonomous PentestingAI agents that find and validate exploitable vulnerabilities like this one across your applications.
• PR ReviewsPentest every pull request so vulnerable code is caught before it ships to production.
• AI Penetration TestingHow AI-driven penetration testing continuously covers your attack surface.

• CVE-2026-52971In the Linux kernel, the following vulnerability has been re…7.8
• CVE-2026-52972In the Linux kernel, the following vulnerability has been re…5.5
• CVE-2026-52973In the Linux kernel, the following vulnerability has been re…7.8
• CVE-2026-52974In the Linux kernel, the following vulnerability has been re…7.5
• CVE-2026-52975In the Linux kernel, the following vulnerability has been re…7.8
• CVE-2026-52976In the Linux kernel, the following vulnerability has been re…7.8
• CVE-2026-52978In the Linux kernel, the following vulnerability has been re…5.5
• CVE-2026-52979In the Linux kernel, the following vulnerability has been re…5.5
• CVE-2026-52980In the Linux kernel, the following vulnerability has been re…5.5
• CVE-2026-52981In the Linux kernel, the following vulnerability has been re…7.5
• CVE-2026-52982In the Linux kernel, the following vulnerability has been re…9.8
• CVE-2026-52983In the Linux kernel, the following vulnerability has been re…7.5