CVE-2026-52977

What it actually does

This is a Linux kernel futex race condition in priority-inheritance requeue handling. A task leaving futex_wait_requeue_pi() because of a timeout or signal can mark its requeue state while another task is performing futex_requeue() and holding the relevant hash-bucket locks. Under specific scheduling conditions, especially when the requeueing task has higher priority or on single-CPU systems, the waiter cannot acquire the lock needed to remove itself from the queue, while the requeueing task repeatedly retries and makes no progress. The result is a kernel-level livelock or CPU-consuming lockup, causing denial of service rather than code execution or privilege escalation based on the available description.

Why it matters to the business

Successful exploitation can cause affected Linux systems to become unresponsive, consume CPU, stall workloads, or require reboot/recovery, creating availability risk for servers, appliances, containers hosts, embedded systems, and real-time workloads. The current public exploitation signal is low: EPSS is 0.00123, it is not listed in CISA KEV, there is no known ransomware association, and exploit maturity is reported as none. However, because futexes are widely used by multithreaded Linux applications, organizations running exposed multi-user systems, container platforms, or untrusted local workloads should still treat kernel updates as important operational resilience work.

How an attack unfolds

An attacker needs the ability to run code locally on an affected Linux system or to trigger local workload behavior that exercises futex wait-requeue priority-inheritance paths. The attacker creates threads using futex operations that enter a wait-requeue-PI state, then coordinates timeout or signal wakeups while another thread performs a requeue-PI operation. By manipulating timing, priority, and scheduling conditions, the attacker attempts to place one task in early wakeup/removal while another task repeatedly holds and reacquires the futex hash-bucket locks. If the race is won, the kernel can livelock in the futex requeue path, causing high CPU usage, soft lockups, hung tasks, or system-wide unresponsiveness. This is most relevant where untrusted users, sandboxed code, containers, or tenant workloads can execute on the same kernel.

How to fix it

Upgrade the Linux kernel to a version that includes the upstream futex fix for this issue. Because no product-specific affected or fixed versions were provided, use the kernel packages supplied by the relevant Linux distribution, appliance vendor, cloud image provider, or embedded platform vendor and verify their advisories explicitly mention this CVE or the futex requeue-PI livelock fix. Reboot systems after installing the kernel update unless live patching is explicitly supported and confirmed to include this fix. Where immediate patching is not possible, reduce exposure by limiting untrusted local code execution, restricting shell access, isolating multi-tenant workloads, constraining container privileges, applying CPU and process limits, and monitoring for kernel soft-lockup or hung-task symptoms. Mitigations do not fully remove the kernel race; patching is the durable fix.

How to confirm the fix worked

Confirm that deployed kernel packages are at or above the vendor-fixed release level and that the running kernel after reboot matches the installed fixed kernel. Validate with commands such as uname -r, package-manager queries, and vendor advisory checks. Review distribution changelogs or kernel source history for the futex requeue-PI fix that removes the top waiter when futex_requeue_pi_prepare() fails and adjusts early requeue wakeup removal behavior. For exposure validation, inventory Linux hosts and container nodes running older kernels, especially systems allowing local users, CI jobs, containers, plugins, or untrusted workloads. For functional validation in test environments only, run vendor or kernel regression tests for futex and priority-inheritance behavior; avoid running untrusted proof-of-concept stressors on production systems because the expected failure mode is denial of service.

Typical attack path

1. Obtain the ability to execute code on an affected Linux kernel, such as through a local shell, compromised application account, container workload, or untrusted user session.
2. Run a multithreaded program that uses futex wait-requeue priority-inheritance behavior.
3. Create timing conditions where one thread exits futex_wait_requeue_pi() because of a timeout or signal while another thread performs futex_requeue().
4. Manipulate scheduling or thread priority to increase the chance that the requeueing thread repeatedly reacquires the futex hash-bucket locks before the waiting thread can remove itself.
5. Trigger the livelock condition, resulting in kernel CPU spinning, soft lockups, hung tasks, or host unresponsiveness.
6. Force operational disruption until the system recovers, the process is terminated, or the host is rebooted.

How to detect it

Look for evidence of kernel livelock or denial-of-service behavior rather than conventional malware artifacts. Useful sources include kernel logs, system journal, console logs, hypervisor reset records, endpoint telemetry, host performance metrics, and container/platform audit logs showing local workload execution immediately before instability. Search for soft-lockup, hard-lockup, hung-task, watchdog, RCU stall, and futex-related stack traces. Correlate these with sudden CPU saturation, loss of host responsiveness, forced reboots, node-not-ready events, container restarts, or user processes that created many threads and signals/timeouts. If available, collect vmcore/kdump data and inspect kernel stacks for futex_requeue(), futex_wait_requeue_pi(), futex_proxy_trylock_atomic(), futex_requeue_pi_prepare(), or handle_early_requeue_pi_wakeup(). Because this issue is a race-condition denial of service, absence of logs does not prove absence of exploitation; systems may freeze before complete telemetry is written.

• BUG: soft lockup
• BUG: hard LOCKUP
• watchdog: BUG: soft lockup
• watchdog: Watchdog detected hard LOCKUP
• INFO: task
• blocked for more than
• rcu: INFO: rcu_preempt detected stalls
• rcu: INFO: rcu_sched detected stalls
• NMI watchdog: Watchdog detected hard LOCKUP
• kernel: futex_requeue
• kernel: futex_wait_requeue_pi
• kernel: futex_proxy_trylock_atomic
• kernel: futex_requeue_pi_prepare
• kernel: handle_early_requeue_pi_wakeup
• futex_requeue()
• futex_wait_requeue_pi()
• futex_proxy_trylock_atomic()
• futex_requeue_pi_prepare()
• handle_early_requeue_pi_wakeup()

What your security team should do

• Prioritize kernel updates for multi-user Linux servers, container hosts, virtualization hosts, CI/build workers, edge appliances, and systems running untrusted or semi-trusted local code.
• Track vendor advisories for the exact distribution kernel package that includes the futex requeue-PI fix; no universal fixed version can be inferred from the provided data.
• Schedule reboots or validated live-patching windows, because installing a fixed kernel without running it does not remediate the live system.
• Monitor for kernel soft lockups, hung tasks, watchdog resets, RCU stalls, and unexplained CPU saturation on Linux hosts until remediation is complete.
• Apply compensating controls where patching is delayed: reduce local user access, limit container privileges, enforce cgroup CPU/process limits, and isolate untrusted workloads from critical hosts.
• Treat exploitation likelihood as currently low because the vulnerability is not in KEV, has low EPSS, and has no known public exploit maturity, but do not ignore it on high-availability or shared-kernel platforms.