CVE-2025-39977

What it actually does

Use-after-free in futex requeue-PI path allowing a task to exit without proper synchronization on futex_q, leading to invalid memory access during subsequent wake_up_state from another thread.

Why it matters to the business

Linux systems may experience crashes, denial of service, or potential privilege escalation, disrupting operations especially in containerized or multi-tenant environments with high process concurrency.

How an attack unfolds

An attacker crafts concurrent futex_wait_requeue_pi and futex_requeue calls to trigger a race where one thread frees futex_q state while another performs a wakeup, potentially leading to memory corruption; related campaigns such as VMSCAPE have targeted similar Linux kernel issues for escalation on container-optimized OS.

How to fix it

Upgrade Linux kernel to commit cb5d19a61274b51b49601214a87af573b43d60fa or later; for SUSE Linux Enterprise Module for Basesystem 15 update mutt to 1.10.1-3.3.4 or equivalent patched package; apply vendor updates immediately given the kernel-wide exposure.

How to confirm the fix worked

Verify kernel version or commit hash matches fixed version; review futex.c for READ_ONCE on futex_q::task before requeue_state update; test with syzkaller or similar concurrency fuzzers targeting requeue_pi paths.

Typical attack path

1. Identify target system running vulnerable Linux kernel with futex usage.
2. Spawn multiple threads performing requeue-PI futex operations to induce the race window.
3. Trigger timeout or signal on waiting thread after requeue completes but before state update.
4. Exploit resulting use-after-free for memory corruption or code execution.

How to detect it

Search kernel logs and audit trails for unusual futex-related crashes or warnings around requeue operations; correlate with container escape attempts or privilege changes in environments targeted by VMSCAPE-style campaigns.

What your security team should do

• Prioritize kernel updates on all production Linux hosts within 48 hours due to privilege escalation potential.
• Monitor for related threat actor activity such as VMSCAPE in container environments.
• Enable kernel hardening features like KASAN in test environments to catch use-after-free during validation.
• Restrict unprivileged futex usage where possible via seccomp filters on high-risk workloads.