From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 3B9E733F59E for ; Sat, 2 May 2026 17:24:45 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777742686; cv=none; b=eze+Ha/R5+to3URd21JoZlS70x4Fe82Yaam419mxGXE0/aerAUtCrXFS3DinDQmVaSqEruO6lkFEWmVqYsYsKfwR9YsRnrkr8zQCtH4APW7TILq3c+iMZN7dJcBbLscxfkMj01/MpgikjQg+VNuGfINhoqhiCj1dZi5GWmZq80A= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777742686; c=relaxed/simple; bh=vmKzDutJWCWUsGIvxQ9ktxQxuZTD2fT0yAdNBt2VkvE=; h=Date:From:To:Cc:Subject:Message-Id:In-Reply-To:References: Mime-Version:Content-Type; b=F8VgNiJM0/kQRAZbSPjN1bhBMvro8fRdaJZwSO07tkQuslKMPuddGAHrR6Do3MSk4pOssG9lrfkLTrfJwNT+liYVmlLtZ95Qq0wAEzYevBQDBG2r/oO1++2TKmVPEl3wtxhX/gKfiesyPeMZQRysxw3MXK+yRVsGG3vWoEJ9Ylg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b=l9t687VF; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="l9t687VF" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 67FB3C19425; Sat, 2 May 2026 17:24:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1777742685; bh=vmKzDutJWCWUsGIvxQ9ktxQxuZTD2fT0yAdNBt2VkvE=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=l9t687VF+510w1MStA0+8d/lbOqZ+cA9LKosEwhCpj44KI/tHY0mKU70II+E4n54S yLST5xKVcnqWpazdY117VUBx1Gv+fMxyphrOPDi+0eK5uoBxidDznYHrZV9Dl+YcYr rHVl4oY7tuRr/xSaEK3Czfzbnzc4flta+e5664Cs= Date: Sat, 2 May 2026 10:24:36 -0700 From: Andrew Morton To: Mohamed Ayman Cc: Kees Cook , Ingo Molnar , Peter Zijlstra , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Valentin Schneider , K Prateek Nayak , David Hildenbrand , Lorenzo Stoakes , "Liam R. Howlett" , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , "Borislav Petkov (AMD)" , Sebastian Andrzej Siewior , linux-mm@kvack.org (open list:EXEC & BINFMT API, ELF), linux-kernel@vger.kernel.org (open list:SCHEDULER), Davidlohr Bueso , Yiming Qian , Linus Torvalds , Sebastian Andrzej Siewior Subject: Re: [PATCH] futex: Drop CLONE_THREAD requirement for private default hash alloc Message-Id: <20260502102436.79d5e53038169f38e4075137@linux-foundation.org> In-Reply-To: <20260502155730.430232-1-mohamedaymanworkspace@gmail.com> References: <20260502155730.430232-1-mohamedaymanworkspace@gmail.com> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; x86_64-pc-linux-gnu) 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-Transfer-Encoding: 7bit On Sat, 2 May 2026 18:57:29 +0300 Mohamed Ayman wrote: > From: Davidlohr Bueso > > Currently need_futex_hash_allocate_default() depends on strict pthread > semantics, abusing CLONE_THREAD. This breaks the non-concurrency > assumptions when doing the mm->futex_ref pcpu allocations, leading to > bugs[0] when sharing the mm in other ways; ie: > > BUG: KASAN: slab-use-after-free in futex_hash_put > > ... where the +1 bias can end up on a percpu counter that mm->futex_ref > no longer points at. > > Loosen the check to cover any CLONE_VM clone, except vfork(). Excluding > vfork keeps the existing paths untouched (no overhead), and we can't > race in the first place: either the parent is suspended and the child > runs alone, or mm->futex_ref is already allocated from an earlier > CLONE_VM. > > Link: https://lore.kernel.org/all/CAL_bE8LsmCQ-FAtYDuwbJhOkt9p2wwYQwAbMh=PifC=VsiBM6A@mail.gmail.com/ [0] > Fixes: d9b05321e21e ("futex: Move futex_hash_free() back to __mmput()") > Reported-by: Yiming Qian > Signed-off-by: Davidlohr Bueso > Signed-off-by: Linus Torvalds I hate to get all bureaucratic, but.... Given what you've sent and from my reading of the security@ and linux-kernel@ lists, - I can't find a patch from Davidlohr which looks like this one - I can't figure out where you got that from. - I can't find any code from Linus which would lead to the addition of his Signed-off-by:. I don't know where you got that from either. - Let's cc the author of the Fixes target, Sebastian? I'd like to have this metadata tightened up, please - so a reader of this patch can understand who did & said what and when and why. Thanks. > kernel/fork.c | 12 +++++------- > 1 file changed, 5 insertions(+), 7 deletions(-) > > diff --git a/kernel/fork.c b/kernel/fork.c > index f1ad69c6dc2d..5f3fdfdb14c7 100644 > --- a/kernel/fork.c > +++ b/kernel/fork.c > @@ -1951,9 +1951,11 @@ static void rv_task_fork(struct task_struct *p) > > static bool need_futex_hash_allocate_default(u64 clone_flags) > { > - if ((clone_flags & (CLONE_THREAD | CLONE_VM)) != (CLONE_THREAD | CLONE_VM)) > - return false; > - return true; > + /* > + * Allocate a default futex hash for any sibling that will > + * share the parent's mm, except vfork. > + */ > + return (clone_flags & (CLONE_VM | CLONE_VFORK)) == CLONE_VM; > } > > /* > @@ -2380,10 +2382,6 @@ __latent_entropy struct task_struct *copy_process( > if (retval) > goto bad_fork_cancel_cgroup; > > - /* > - * Allocate a default futex hash for the user process once the first > - * thread spawns. > - */ > if (need_futex_hash_allocate_default(clone_flags)) { > retval = futex_hash_allocate_default(); > if (retval) > -- > 2.34.1