From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 39C34408240 for ; Tue, 24 Mar 2026 17:44:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=90.155.50.34 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774374265; cv=none; b=IGVAmtpTSlkWxm7nS8tgtts9XGdgQaE/0PY/7ehMtZXXCfmgaqLjxCyGGIIuR8/elTEQjLZdL3b/xQoKgQSwrzin7OKDlknhh3s+LWbnYShZxj1RiM2yLvfTGwje5eOwv0Hm7MP7cxh6LDdWvKjON9MBBNVzGR8Mbu7KvDPM5BM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774374265; c=relaxed/simple; bh=qIm9TWmHDjNT4btiLRWoSqlbLCAwrg+PhHcwnX2mFro=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=sIieldRufD++LsJutoOmU9DKUXe3Clti/y4HmKqe0OK1+MIXhtX1H1sMXaVaI8I13O7YE8IN9YTCr+cGw+qqQ1dFcK91kTDMTjSU5S1c4R8PfwNUtcf/kWUfOXXQV6hUTlYAdeeVou0v2m4cAQdbDSGf3QUL8fkcSY9uMfpAdJg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org; spf=none smtp.mailfrom=infradead.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b=bTYHRtBq; arc=none smtp.client-ip=90.155.50.34 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=infradead.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="bTYHRtBq" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=W085LUSAi9mVXxNSZ1ANPdA+9qLKpFq/9UOGT2qvriI=; b=bTYHRtBqlKsXaeVMwCCnHZi+mE oHqXXubk3u4IlvBuPJAvrdC0XXH5IzQULbQ3WvyY1GE89qPJzBJ5t61sZ6mKKD5SnI8LqQ1NsjyL+ m6o5Dq/a9ygDxuDgWaedZ0JBxmn5A03RmT0xqcwlL6m3FJ2fx/ayzKOFurtgXbkJMXvItSi3YQWJ6 f0ynHhQMsLr2T/2gyjW1K62xPGC/8PbuKH9Cz5SsA6HSk7kJOdtarcp+nmUqjHg4KlwaXMiIlHuHG +9c14O4O9zx/bcohC8hsfEvS0bzPQZ5bWjHmIeMXkWxnx+t0SSa+2hv47SaKR8meqMuFxdfUwKUgr 2TJMohxw==; Received: from 77-249-17-252.cable.dynamic.v4.ziggo.nl ([77.249.17.252] helo=noisy.programming.kicks-ass.net) by casper.infradead.org with esmtpsa (Exim 4.98.2 #2 (Red Hat Linux)) id 1w55nf-0000000EOYl-0JX3; Tue, 24 Mar 2026 17:44:19 +0000 Received: by noisy.programming.kicks-ass.net (Postfix, from userid 1000) id 8C3E73002D8; Tue, 24 Mar 2026 18:44:18 +0100 (CET) Date: Tue, 24 Mar 2026 18:44:18 +0100 From: Peter Zijlstra To: Thomas Gleixner Cc: Hao-Yu Yang , mingo@redhat.com, linux-kernel@vger.kernel.org, Andrew Morton , David Hillenbrand , Eric Dumazet , linux-mm@kvack.org Subject: Re: [PATCH v2] futex: Use-after-free between futex_key_to_node_opt and vma_replace_policy Message-ID: <20260324174418.GB1850007@noisy.programming.kicks-ass.net> References: <20260313124756.52461-1-naup96721@gmail.com> <87a4vyihlx.ffs@tglx> <20260324140019.GE3738010@noisy.programming.kicks-ass.net> <87fr5pgp5x.ffs@tglx> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87fr5pgp5x.ffs@tglx> 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 Date: Fri, 13 Mar 2026 20:47:56 +0800 From: Hao-Yu Yang 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 Suggested-by: Eric Dumazet Signed-off-by: Hao-Yu Yang Signed-off-by: Peter Zijlstra (Intel) --- 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");