CVE-2026-74658

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> futex: Prevent robust futex exit race some more<br /> <br /> A robust futex unlock stores 0 over the whole futex value - wiping<br /> FUTEX_WAITERS - and wakes a single waiter. That wakeup is a one-shot<br /> notification: the protocol relies on its recipient to either acquire the<br /> futex (and eventually unlock while aware of the remaining contention) or<br /> re-arm FUTEX_WAITERS before sleeping again. If the woken waiter is killed<br /> before it can do either, the kernel must jump in and wake the next task<br /> down the line.<br /> <br /> This is a known complication of the futex protocol with a previous<br /> partial fix in commit ca16d5bee598 ("futex: Prevent robust futex exit<br /> race"). Unfortunately, that fix is insufficient.<br /> <br /> If a third task re-acquired the futex through the uncontended fast<br /> path in the meantime, the notification is lost: robust exit processing<br /> sees that it is owned by another task and does nothing, while the new<br /> owner sees no FUTEX_WAITERS when it unlocks and wakes nobody.<br /> The remaining waiters sleep forever behind a free futex:<br /> <br /> A owns the futex, B and C sleep in FUTEX_WAIT<br /> uval == A | FUTEX_WAITERS<br /> A robust unlock: store 0, FUTEX_WAKE(1) wakes B<br /> uval == 0<br /> D fast path acquire: cmpxchg(0 -&gt; D)<br /> uval == D, no FUTEX_WAITERS<br /> B killed before acting on the wakeup<br /> B exit walk, pending op: owner D != B -&gt; no action<br /> D unlock: no FUTEX_WAITERS -&gt; no wake<br /> C sleeps forever<br /> <br /> This is clearly a shortcoming in the implementation, which fails to keep<br /> the FUTEX_WAITERS bit consistent.<br /> <br /> Work around this by augmenting the robust list exit processing to also<br /> perform the extra wakeup if the futex word is owned by another thread but<br /> FUTEX_WAITERS is not set.<br /> <br /> This does not fix the problem of a non-contended take over/release and free<br /> sequence, which has been discussed for years and has been addressed by<br /> commit 3ca9595d9fb6 ("futex: Add support for unlocking robust futexes") and<br /> subsequent changes, but failed to take the problem described above into<br /> account.<br /> <br /> A more complete solution which is based on the in kernel unlock of<br /> contended robust futexes has been discussed in the context of this change<br /> and should show up in mainline sooner than later.<br /> <br /> [ tglx: Amend change log slightly and fixup coding style ]