mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Hyunwoo Kim <imv4bel@gmail.com>
Cc: tglx@kernel.org, mingo@redhat.com, dvhart@infradead.org,
	dave@stgolabs.net, andrealmeid@igalia.com,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] futex: Fix race on the initial mm->futex.phash.ref allocation
Date: Wed, 12 Aug 2026 12:57:05 +0200	[thread overview]
Message-ID: <20260812105705.GK776954@noisy.programming.kicks-ass.net> (raw)
In-Reply-To: <ansrpP4ImE1MaBY9@v4bel>

On Tue, Aug 11, 2026 at 11:03:16PM +0900, Hyunwoo Kim wrote:
> futex_hash_allocate() allocates mm->futex.phash.ref without any locking.
> Commit d9b05321e21e ("futex: Move futex_hash_free() back to __mmput()")
> moved the allocation here and assumed that the process has just a single
> thread at this point.
> 
> Commit ee9dce44362b ("futex: Drop CLONE_THREAD requirement for private
> default hash alloc") widened need_futex_hash_allocate_default() to cover
> any CLONE_VM clone, but left out vfork because the parent is suspended and
> cannot race.
> 
> That no longer holds once vfork is nested. If a vfork child calls vfork
> again and is then killed with SIGKILL, the parent is released from its
> vfork wait and runs concurrently with the grandchild in the same mm.
> Neither of them went through futex_hash_allocate_default().
> 
> When both call prctl(PR_FUTEX_HASH, PR_FUTEX_HASH_SET_SLOTS) at the same
> time, each one sees mm->futex.phash.ref as NULL and stores its own percpu
> counter. Only the last store survives. The counter stored first is no
> longer reachable from the mm, so the references on it are not seen by
> __futex_ref_atomic_end(). A private hash that still has references is then
> considered dead and freed, and a task that still holds one of its buckets
> writes into freed memory in futex_q_lock().
> 
> Store the counter once with cmpxchg() and let the loser free_percpu() its
> own. The initial reference has to be taken before the store, otherwise
> another task can install a private hash while the counter is still 0.
> 
> Fixes: d9b05321e21e ("futex: Move futex_hash_free() back to __mmput()")
> Cc: stable@vger.kernel.org
> Signed-off-by: Hyunwoo Kim <imv4bel@gmail.com>

Yep :-( I'll go stick this in locking/urgent. Thanks!

> ---
>  kernel/futex/core.c | 16 ++++++++++------
>  1 file changed, 10 insertions(+), 6 deletions(-)
> 
> diff --git a/kernel/futex/core.c b/kernel/futex/core.c
> index 128c5752f225c2..806576978fa84c 100644
> --- a/kernel/futex/core.c
> +++ b/kernel/futex/core.c
> @@ -1842,14 +1842,18 @@ static int futex_hash_allocate(unsigned int hash_slots, unsigned int flags)
>  	}
>  
>  	if (!mm->futex.phash.ref) {
> +		unsigned int __percpu *ref = alloc_percpu(unsigned int);
> +
> +		if (!ref)
> +			return -ENOMEM;
> +
>  		/*
> -		 * This will always be allocated by the first thread and
> -		 * therefore requires no locking.
> +		 * Tasks sharing the mm can run this concurrently, so take the
> +		 * initial reference before publishing the counter.
>  		 */
> -		mm->futex.phash.ref = alloc_percpu(unsigned int);
> -		if (!mm->futex.phash.ref)
> -			return -ENOMEM;
> -		this_cpu_inc(*mm->futex.phash.ref); /* 0 -> 1 */
> +		this_cpu_inc(*ref); /* 0 -> 1 */
> +		if (cmpxchg(&mm->futex.phash.ref, NULL, ref))
> +			free_percpu(ref);
>  	}
>  
>  	fph = kvzalloc(struct_size(fph, queues, hash_slots),
> -- 
> 2.43.0
> 

  reply	other threads:[~2026-08-12 10:57 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-11 14:03 Hyunwoo Kim
2026-08-12 10:57 ` Peter Zijlstra [this message]
2026-08-12 11:02 ` [tip: locking/urgent] " tip-bot2 for Hyunwoo Kim

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260812105705.GK776954@noisy.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=andrealmeid@igalia.com \
    --cc=dave@stgolabs.net \
    --cc=dvhart@infradead.org \
    --cc=imv4bel@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=tglx@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®