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

[Thomas Gleixner <tglx@kernel.org>]

On Tue, Jul 21 2026 at 12:50, Keno Fischer wrote:
> On Tue, 21 Jul 2026 14:24:34 +0200, Thomas Gleixner <tglx@kernel.org> wrote:
>> On Mon, Jul 20 2026 at 23:26, Keno Fischer wrote:
>>> 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@kernel.org/
>>
>> which is upstream now. Specifically the combined unlock/wake part
>>
>>    https://lore.kernel.org/all/20260602090535.670514505@kernel.org/
>>
>> ensures that your scenario can't happen and provides at the same time
>> one part of the solution for the UAF exit race.
>
> Yes, I'm aware of that patch series.
> However, this is not quite the same race.
> As the updated comment indicates, the combined unlock/wake prevents one
> of the three race scenarios that causes problems.
> However, if a *woken up* task dies before it can re-acquire the futex,
> the kernel must still pass the baton down the line to the next task.
> The existing code handled this case for the scenario where there was no
> interfering third task (the second scenario in the original comment).
> However, the possibility that a third task could perform an uncontested
> acquire in the meantime was not accounted for.

Which means that the handling of the FUTEX_WAITER bit for robust non-PI
futexes in the unlock path is inconsistent, which means the
unconditional store 0 is the real problem.

We should rather fix that than hacking around it in the exit handling
code.

Let me think about it some more.

>>> 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?
>
> I was planning to write it up with that patch series, but here's
> the abbreviated version: Embedded databases (e.g. LMBD) use
> shared-memory robust mutexes (glibc pthread_mutex in the LMDB case)
> to coordinate access to the database file among users. However, if
> those users are in different pid namespaces, the mutex silently fails
> to provide mutual exclusion, causing corruption and hangs (bad for a
> database).

Unsurprisingly a robust futex depends on unique PIDs, which are not
obviously not guaranteed accross multiple PID namespaces.

TBH, I'm not really keen to see the hacks required to make this "work"
and thereby violating all isolation rules which come with namespaces.

Thanks,

        tglx