CVE-2025-39977

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> futex: Prevent use-after-free during requeue-PI<br /> <br /> syzbot managed to trigger the following race:<br /> <br /> T1 T2<br /> <br /> futex_wait_requeue_pi()<br /> futex_do_wait()<br /> schedule()<br /> futex_requeue()<br /> futex_proxy_trylock_atomic()<br /> futex_requeue_pi_prepare()<br /> requeue_pi_wake_futex()<br /> futex_requeue_pi_complete()<br /> /* preempt */<br /> <br /> * timeout/ signal wakes T1 *<br /> <br /> futex_requeue_pi_wakeup_sync() // Q_REQUEUE_PI_LOCKED<br /> futex_hash_put()<br /> // back to userland, on stack futex_q is garbage<br /> <br /> /* back */<br /> wake_up_state(q-&gt;task, TASK_NORMAL);<br /> <br /> In this scenario futex_wait_requeue_pi() is able to leave without using<br /> futex_q::lock_ptr for synchronization.<br /> <br /> This can be prevented by reading futex_q::task before updating the<br /> futex_q::requeue_state. A reference on the task_struct is not needed<br /> because requeue_pi_wake_futex() is invoked with a spinlock_t held which<br /> implies a RCU read section.<br /> <br /> Even if T1 terminates immediately after, the task_struct will remain valid<br /> during T2&amp;#39;s wake_up_state(). A READ_ONCE on futex_q::task before<br /> futex_requeue_pi_complete() is enough because it ensures that the variable<br /> is read before the state is updated.<br /> <br /> Read futex_q::task before updating the requeue state, use it for the<br /> following wakeup.