CVE-2026-52977

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> futex: Prevent lockup in requeue-PI during signal/ timeout wakeup<br /> <br /> During wait-requeue-pi (task A) and requeue-PI (task B) the following<br /> race can happen:<br /> <br /> Task A Task B<br /> futex_wait_requeue_pi()<br /> futex_setup_timer()<br /> futex_do_wait()<br /> futex_requeue()<br /> CLASS(hb, hb1)(&amp;key1);<br /> CLASS(hb, hb2)(&amp;key2);<br /> *timeout*<br /> futex_requeue_pi_wakeup_sync()<br /> requeue_state = Q_REQUEUE_PI_IGNORE<br /> <br /> *blocks on hb-&gt;lock*<br /> <br /> futex_proxy_trylock_atomic()<br /> futex_requeue_pi_prepare()<br /> Q_REQUEUE_PI_IGNORE =&gt; -EAGAIN<br /> double_unlock_hb(hb1, hb2)<br /> *retry*<br /> <br /> Task B acquires both hb locks and attempts to acquire the PI-lock of the<br /> top most waiter (task B). Task A is leaving early due to a signal/<br /> timeout and started removing itself from the queue. It updates its<br /> requeue_state but can not remove it from the list because this requires<br /> the hb lock which is owned by task B.<br /> <br /> Usually task A is able to swoop the lock after task B unlocked it.<br /> However if task B is of higher priority then task A may not be able to<br /> wake up in time and acquire the lock before task B gets it again.<br /> Especially on a UP system where A is never scheduled.<br /> <br /> As a result task A blocks on the lock and task B busy loops, trying to<br /> make progress but live locks the system instead. Tragic.<br /> <br /> This can be fixed by removing the top most waiter from the list in this<br /> case. This allows task B to grab the next top waiter (if any) in the<br /> next iteration and make progress.<br /> <br /> Remove the top most waiter if futex_requeue_pi_prepare() fails.<br /> Let the waiter conditionally remove itself from the list in<br /> handle_early_requeue_pi_wakeup().