Re: [PATCH] futex: Prevent robust futex exit race more

[Thomas Gleixner]

On Mon, Jul 20 2026 at 23:26, Keno Fischer wrote:
> If a third task re-acquired the futex through the uncontended fast
> path in the meantime, the notification is lost: Robust exit processing
> sees that it is owned by another task and does nothing, while the new
> owner sees no FUTEX_WAITERS when it unlocks and wakes nobody.
> The remaining waiters sleep forever behind a free futex:
>
>   A owns the futex, B and C sleep in FUTEX_WAIT
>                                         uval == A | FUTEX_WAITERS
>   A robust unlock: store 0, FUTEX_WAKE(1) wakes B
>                                         uval == 0
>   D fast path acquire: cmpxchg(0 -> D)
>                                         uval == D, no FUTEX_WAITERS
>   B killed before acting on the wakeup
>   B exit walk, pending op: owner D != B -> no action
>   D unlock: no FUTEX_WAITERS -> no wake
>                                         C sleeps forever
>
> Fix this by augmenting the robust list exit processing to also
> perform the extra wakeup if the futex word is owned by another
> thread but FUTEX_WAITERS is *NOT* set.

While your change "fixes" this particular problem, it leaves the related
UAF problem unsolved.

The more complete solution is:

   https://lore.kernel.org/all/20260602084648.462672743@xxxxxxxxxx/

which is upstream now. Specifically the combined unlock/wake part

   https://lore.kernel.org/all/20260602090535.670514505@xxxxxxxxxx/

ensures that your scenario can't happen and provides at the same time
one part of the solution for the UAF exit race.

> This issues was discovered as part of a larger attempt to resolve the
> long-standing issue that robust futexes are not safely usable across
> pid namespaces.

What's the actual problem with that?

Thanks,

        tglx