CVE-2025-39977

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.