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

[Peter Zijlstra]

On Mon, Mar 30, 2026 at 02:45:59PM +0100, Mark Rutland wrote:
> 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@xxxxxxxxxx
> > 
> > The v1 cover letter contains a detailed analysis of the underlying
> > problem:
> > 
> >     https://lore.kernel.org/20260316162316.356674433@xxxxxxxxxx
> > 
> > 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.
> 

ARM64 (and all the other archs) need the relevant VDSO bits as well.

> > 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).

Indeed!