Re: [patch V3 00/14] futex: Address the robust futex unlock race for real

[Mark Rutland <mark.rutland@arm.com>]

On Mon, Mar 30, 2026 at 02:01:58PM +0200, Thomas Gleixner wrote:
> This is a follow up to v2 which can be found here:
> 
>      https://lore.kernel.org/20260319225224.853416463@kernel.org
> 
> The v1 cover letter contains a detailed analysis of the underlying
> problem:
> 
>     https://lore.kernel.org/20260316162316.356674433@kernel.org
> 
> TLDR:
> 
> The robust futex unlock mechanism is racy in respect to the clearing of the
> robust_list_head::list_op_pending pointer because unlock and clearing the
> pointer are not atomic. The race window is between the unlock and clearing
> the pending op pointer. If the task is forced to exit in this window, exit
> will access a potentially invalid pending op pointer when cleaning up the
> robust list. That happens if another task manages to unmap the object
> containing the lock before the cleanup, which results in an UAF. In the
> worst case this UAF can lead to memory corruption when unrelated content
> has been mapped to the same address by the time the access happens.
> 
> User space can't solve this problem without help from the kernel. This
> series provides the kernel side infrastructure to help it along:
> 
>   1) Combined unlock, pointer clearing, wake-up for the contended case
> 
>   2) VDSO based unlock and pointer clearing helpers with a fix-up function
>      in the kernel when user space was interrupted within the critical
>      section.

I see the vdso bits in this series are specific to x86. Do other
architectures need something here?

I might be missing some context; I'm not sure whether that's not
necessary or just not implemented by this series, and so I'm not sure
whether arm64 folk and other need to go dig into this.

[...]

> Changes since v2:

>   - Rename ARCH_STORE_IMPLIES_RELEASE to ARCH_MEMORY_ORDER_TOS - Peter

I believe that should be s/TOS/TSO/, since the standard terminology is
Total Store Order (TSO).

Mark.