Re: [PATCH v2] futex: Use-after-free between futex_key_to_node_opt and vma_replace_policy

["David Hildenbrand (Arm)" <david@kernel.org>]

On 3/24/26 18:44, Peter Zijlstra wrote:
> On Tue, Mar 24, 2026 at 05:36:42PM +0100, Thomas Gleixner wrote:
>> On Tue, Mar 24 2026 at 15:00, Peter Zijlstra wrote:
>>> Not to mention we don't actually need any of that here, because:
>>>
>>>
>>> The vma->vm_policy thing is written under mmap_lock held for writing,
>>> and the futex consumer is a speculative read lock. Specifically the
>>> ordering is through the associated seqcount.
>>
>> Duh. Yes.
>>
>>> All that is really needed is to extend the lifetime of the mpol to the
>>> associated RCU period. Which is exactly what this patch does.
>>>
>>> Want me to go write up a better Changelog?
>>
>> And a comment in the code explaining the RCU magic perhaps?
> 
> Does this work for you?
> 

CCing Lorenzo and Liam.

> ---
> Subject: futex: Fix UaF between futex_key_to_node_opt() and vma_replace_policy()
> From: Hao-Yu Yang <naup96721@gmail.com>
> Date: Fri, 13 Mar 2026 20:47:56 +0800
> 
> From: Hao-Yu Yang <naup96721@gmail.com>
> 
> During futex_key_to_node_opt() execution, vma->vm_policy is read under
> speculative mmap lock and RCU. Concurrently, mbind() may call
> vma_replace_policy() which frees the old mempolicy immediately via
> kmem_cache_free().
> 
> This creates a race where __futex_key_to_node() dereferences a freed
> mempolicy pointer, causing a use-after-free read of mpol->mode.
> 
> [  151.412631] BUG: KASAN: slab-use-after-free in __futex_key_to_node (kernel/futex/core.c:349)
> [  151.414046] Read of size 2 at addr ffff888001c49634 by task e/87
> 
> [  151.415969] Call Trace:
> 
> [  151.416732]  __asan_load2 (mm/kasan/generic.c:271)
> [  151.416777]  __futex_key_to_node (kernel/futex/core.c:349)
> [  151.416822]  get_futex_key (kernel/futex/core.c:374 kernel/futex/core.c:386 kernel/futex/core.c:593)
> 
> Fix by adding rcu to __mpol_put().
> 
> Fixes: c042c505210d ("futex: Implement FUTEX2_MPOL")
> Reported-by: Hao-Yu Yang <naup96721@gmail.com>
> Suggested-by: Eric Dumazet <edumazet@google.com>
> Signed-off-by: Hao-Yu Yang <naup96721@gmail.com>
> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
> ---
>  include/linux/mempolicy.h |    1 +
>  mm/mempolicy.c            |    8 +++++++-
>  2 files changed, 8 insertions(+), 1 deletion(-)
> 
> --- a/include/linux/mempolicy.h
> +++ b/include/linux/mempolicy.h
> @@ -55,6 +55,7 @@ struct mempolicy {
>  		nodemask_t cpuset_mems_allowed;	/* relative to these nodes */
>  		nodemask_t user_nodemask;	/* nodemask passed by user */
>  	} w;
> +	struct rcu_head rcu;
>  };
>  
>  /*
> --- a/mm/mempolicy.c
> +++ b/mm/mempolicy.c
> @@ -487,7 +487,13 @@ void __mpol_put(struct mempolicy *pol)
>  {
>  	if (!atomic_dec_and_test(&pol->refcnt))
>  		return;
> -	kmem_cache_free(policy_cache, pol);
> +	/*
> +	 * Required to allow mmap_lock_speculative*() access, see for example
> +	 * futex_key_to_node_opt(). All accesses are serialized by mmap_lock,
> +	 * however the speculative lock section unbound by the normal lock
> +	 * boundaries, requiring RCU freeing.
> +	 */
> +	kfree_rcu(pol, rcu);
>  }
>  EXPORT_SYMBOL_FOR_MODULES(__mpol_put, "kvm");
>  

So IIUC, futex_key_to_node_opt() looks up a VMA under RCU, without
holding the mmap lock. Concurrent mmap-write lock is detected by using
the mmap_lock_speculate_try_begin()/mmap_lock_speculate_retry() seqcount.

After looking up the VMA, we access the VMA policy.

vma_policy() does a straight vma->vm_policy.

What prevents the compiler here to do some load tearing while it is
getting modified by mbind()? Or what stops the writer side to to some
store tearing?

Shouldn't we be using at least READ_ONCE/WRITE_ONCE() etc?


-- 
Cheers,

David