VYPR
Unrated severityNVD Advisory· Published Oct 15, 2025· Updated May 12, 2026

CVE-2025-39977

CVE-2025-39977

Description

In the Linux kernel, the following vulnerability has been resolved:

futex: Prevent use-after-free during requeue-PI

syzbot managed to trigger the following race:

T1 T2

futex_wait_requeue_pi() futex_do_wait() schedule() futex_requeue() futex_proxy_trylock_atomic() futex_requeue_pi_prepare() requeue_pi_wake_futex() futex_requeue_pi_complete() /* preempt */

  • timeout/ signal wakes T1 *

futex_requeue_pi_wakeup_sync() // Q_REQUEUE_PI_LOCKED futex_hash_put() // back to userland, on stack futex_q is garbage

/* back */ wake_up_state(q->task, TASK_NORMAL);

In this scenario futex_wait_requeue_pi() is able to leave without using futex_q::lock_ptr for synchronization.

This can be prevented by reading futex_q::task before updating the futex_q::requeue_state. A reference on the task_struct is not needed because requeue_pi_wake_futex() is invoked with a spinlock_t held which implies a RCU read section.

Even if T1 terminates immediately after, the task_struct will remain valid during T2's wake_up_state(). A READ_ONCE on futex_q::task before futex_requeue_pi_complete() is enough because it ensures that the variable is read before the state is updated.

Read futex_q::task before updating the requeue state, use it for the following wakeup.

AI Insight

LLM-synthesized narrative grounded in this CVE's description and references.

A race condition in the Linux kernel's futex requeue-PI mechanism can cause use-after-free, potentially leading to privilege escalation.

Vulnerability

CVE-2025-39977: Use-After-Free in Linux Kernel Futex Requeue-PI Requeue

A race condition exists in the Linux kernel's futex subsystem, specifically in the futex_wait_requeue_pi() and futex_requeue() code paths. The vulnerability occurs when a thread (T1) waiting on a futex via futex_wait_requeue_pi() is woken by a timeout or signal while a second thread (T2) is concurrently performing a requeue-PI operation. T2's requeue_pi_wake_futex() function updates the requeue state and then attempts to wake T1, but T1 may have already exited the futex wait and returned to user space, leaving the futex_q structure on the stack as garbage. The wake-up operation then accesses freed memory, leading to a use-after-free condition [1].

##Exploitation

An attacker would need to be able to trigger the specific race window between the two threads. This requires local access to the system and the ability to create and control futex operations. The race is triggered when T1's wait is interrupted (by signal or timeout) precisely during the window where T2 has completed the requeue preparation but before the wake-up call. The vulnerability is exploitable because the wake_up_state() call in requeue_pi_wake_futex() uses a pointer to the task that task_struct that may have been freed after T1 returns to user space [1].

##Impact

Successful exploitation could allow an attacker to corrupt kernel memory, potentially leading to privilege escalation, denial of service, or arbitrary code execution in kernel context. The vulnerability is rated with a CVSS score of 7.8 (High) [1].

##Mitigation

The fix, committed to the Linux kernel stable tree, ensures that futex_q::task is read before updating the requeue state, preventing the use a READ_ONCE to guarantee the ordering. This prevents the use-after-free by ensuring the task pointer remains valid during the wake-up call [1]. Users should apply the latest kernel updates from their distribution. The vulnerability affects all kernels prior to the fix, including those used in Siemens SIMATIC S7-1500 CPU family products [1].

References
  1. SSA-082556

AI Insight generated on May 19, 2026. Synthesized from this CVE's description and the cited reference URLs; citations are validated against the source bundle.

Affected products

1

Patches

5

Vulnerability mechanics

Generated on May 9, 2026. Inputs: CWE entries + fix-commit diffs from this CVE's patches. Citations validated against bundle.

References

6

News mentions

0

No linked articles in our index yet.