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

[Keno Fischer]

On Tue, 21 Jul 2026 14:24:34 +0200, Thomas Gleixner <tglx@xxxxxxxxxx> 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@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.

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.

>> 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). We (the Julia programming language project) found this
out when we added an LMDB-backed cache to our compiler. As it
turns out, a significant fraction of our users like to bind mount the
directory in question into their containers (because sharing the
caches makes things faster and they're using the containers for
consistency of environment not as a security boundary) or share
it among multiple different containers (AI sandboxes are a common
example). For now we're detecting this scenario and disabling the
cache, but it doesn't seem like a patently unreasonable use case
to me. Yes, perhaps it's a bit odd to have shared-memory communication
over what is supposed to be a an isolation boundary, but it is what users do
In actual practice.