CVE-2026-52977: Linux Kernel Futex Race Condition Causing System Lockup

Technical summary

CVE-2026-52977 addresses a synchronization race in the futex subsystem occurring during wait-requeue-pi operations. When Task A (waiting with a timeout) and Task B (performing requeue operations) interact, Task A's signal/timeout wakeup can trigger a state where it marks itself for early departure via REQUEUE_PI_IGNORE but cannot acquire the hash bucket lock held by Task B to remove itself from the queue. If Task B has higher priority or runs on a uniprocessor system, it may re-acquire the lock before Task A wakes, causing Task A to block indefinitely while Task B busy-loops attempting futex_requeue_pi_prepare(), effectively creating a livelock. The resolution requires removing the top-most waiter from the list when futex_requeue_pi_prepare() fails, and allowing conditional self-removal in handle_early_requeue_pi_wakeup().

Business impact

This vulnerability can cause complete system unresponsiveness on affected Linux systems, particularly impacting production environments relying on futex-based synchronization primitives. Services using condition variables, mutexes, or other higher-level synchronization mechanisms that depend on futexes are at risk of sudden, unexplained hangs. The impact is most severe on uniprocessor systems or when workloads involve mixed-priority threads, as these conditions maximize the probability of the race triggering. System administrators may experience mysterious service outages without obvious error messages, complicating diagnosis and remediation.

Affected systems

The Linux kernel across all versions containing the vulnerable futex requeue-PI code path is affected. This includes both 32-bit and 64-bit architectures. The vulnerability is most readily triggered on systems with single processors or low core counts, and in workloads that use futex-based synchronization with signal handlers or timers. Any Linux distribution and kernel version prior to the fix is potentially vulnerable.

Exploitability

Exploitation requires local system access and the ability to spawn threads or processes that exercise futex wait-requeue-pi operations with concurrent signal delivery or timeouts. The race condition is probabilistic and more reliably triggered on uniprocessor systems or with careful timing manipulation. No special privileges are required beyond normal user-level thread creation and signal handling. While not easily weaponized for remote attack, local users can reliably cause denial of service by forcing the system lockup condition.

Remediation

Apply the Linux kernel patch that modifies futex requeue-PI handling to remove top-most waiters when futex_requeue_pi_prepare() fails, and implements conditional self-removal in handle_early_requeue_pi_wakeup(). Verify the fix by checking kernel release notes or commit history for the specific futex subsystem changes addressing this race condition. Reboot systems after patching to activate the corrected kernel code.

Patch guidance

Update to a Linux kernel version containing the fix for CVE-2026-52977. Verify against your distribution's security advisory and kernel changelog to confirm the specific version or commit that resolves this issue. Most major distributions (Red Hat, Ubuntu, Debian, SUSE, etc.) will provide patched kernel packages; use your standard kernel update mechanism (e.g., apt, yum, zypper) to deploy the corrected version. Test in non-production environments before rolling out to critical systems, as kernel updates require reboots. Prioritize patching on uniprocessor systems and those running multi-threaded workloads with signal handling.

Detection guidance

Affected systems may exhibit symptoms of kernel hangs, lockups, or unresponsive processes without clear error messages in system logs. Monitor system logs (dmesg, /var/log/kern.log) for signs of RCU stall warnings, soft lockup warnings, or watchdog timeouts, which often precede or accompany futex-related deadlocks. Use kernel tracing tools (ftrace, perf) to observe futex operations and thread state if reproducing the issue in a lab environment. In production, track process states via ps/top for unexplained 'D' (uninterruptible sleep) states, which may indicate futex deadlock. Correlation with signal delivery or timeout events in application logs can help identify affected workloads.

Why prioritize this

This vulnerability merits priority remediation because it causes denial of service through system lockup, affecting availability—a critical operational concern. Although the attack surface is limited to local access, the impact (complete system freeze) is severe and can disable critical infrastructure. Uniprocessor systems and those running legacy or specialized workloads relying on futex-based libraries (pthreads, boost::thread, etc.) should be prioritized. Organizations running containerized or virtualized environments on single-core instances face elevated risk.

Risk score, explained

The CVSS 3.1 score of 5.5 (MEDIUM, AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H) reflects that the vulnerability requires local access and low privileges, but delivers high availability impact via denial of service. The attack complexity is low—once the conditions align (timeout + higher-priority requeue task), the race is likely to manifest. No confidentiality or integrity impact occurs; the harm is purely denial of service. The score appropriately downgrades from CRITICAL due to the local-access requirement but emphasizes the severity of the availability impact.

Frequently asked questions