Re: [PATCH v2] futex: Use-after-free between futex_key_to_node_opt and vma_replace_policy
From: Peter Zijlstra
Date: Tue Mar 24 2026 - 13:46:43 EST
On Tue, Mar 24, 2026 at 05:36:42PM +0100, Thomas Gleixner wrote:
> On Tue, Mar 24 2026 at 15:00, Peter Zijlstra wrote:
> > On Mon, Mar 23, 2026 at 06:24:42PM +0100, Thomas Gleixner wrote:
> > Not to mention we don't actually need any of that here, because:
> >
> >> Especially the writer side is required so that the proper memory
> >> barriers are inserted for architectures with a weakly ordered memory
> >> model.
> >
> > 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?
---
Subject: futex: Fix UaF between futex_key_to_node_opt() and vma_replace_policy()
From: Hao-Yu Yang <naup96721@xxxxxxxxx>
Date: Fri, 13 Mar 2026 20:47:56 +0800
From: Hao-Yu Yang <naup96721@xxxxxxxxx>
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@xxxxxxxxx>
Suggested-by: Eric Dumazet <edumazet@xxxxxxxxxx>
Signed-off-by: Hao-Yu Yang <naup96721@xxxxxxxxx>
Signed-off-by: Peter Zijlstra (Intel) <peterz@xxxxxxxxxxxxx>
---
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");