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 futexwaitrequeuepi() futexdowait() schedule() futexrequeue() futexproxytrylockatomic() futexrequeuepiprepare() requeuepiwakefutex() futexrequeuepicomplete() /* 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 */ wakeupstate(q->task, TASKNORMAL); In this scenario futexwaitrequeuepi() is able to leave without using futexq::lockptr for synchronization. This can be prevented by reading futexq::task before updating the futexq::requeuestate. A reference on the taskstruct is not needed because requeuepiwakefutex() is invoked with a spinlockt held which implies a RCU read section. Even if T1 terminates immediately after, the taskstruct will remain valid during T2's wakeupstate(). A READONCE on futexq::task before futexrequeuepicomplete() 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.