Wind River Support Network

Description

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