Linux kernel -stable discussions
 help / color / mirror / Atom feed
From: <gregkh@linuxfoundation.org>
To: kylebot@openai.com,peterz@infradead.org,tglx@kernel.org
Cc: <stable@vger.kernel.org>
Subject: FAILED: patch "[PATCH] futex/pi: Reject cross-mm private futex owners" failed to apply to 7.1-stable tree
Date: Mon, 24 Aug 2026 12:56:46 +0200	[thread overview]
Message-ID: <2026082446-lumpish-subdivide-9766@gregkh> (raw)


The patch below does not apply to the 7.1-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable@vger.kernel.org>.

To reproduce the conflict and resubmit, you may use the following commands:

git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-7.1.y
git checkout FETCH_HEAD
git cherry-pick -x 59b3732f95dda1fbd2234514d35f4fb6b5bb6d85
# <resolve conflicts, build, test, etc.>
git commit -s
git send-email --to '<stable@vger.kernel.org>' --in-reply-to '2026082446-lumpish-subdivide-9766@gregkh' --subject-prefix 'PATCH 7.1.y' 'HEAD^..'

Possible dependencies:



thanks,

greg k-h

------------------ original commit in Linus's tree ------------------

From 59b3732f95dda1fbd2234514d35f4fb6b5bb6d85 Mon Sep 17 00:00:00 2001
From: Kyle Zeng <kylebot@openai.com>
Date: Fri, 7 Aug 2026 17:07:03 +0200
Subject: [PATCH] futex/pi: Reject cross-mm private futex owners

A private futex key borrows the waiter's mm without taking an mm_users
reference. Nevertheless, attach_to_pi_owner() currently accepts an owner
from a different address space and copies the private key into the owner's
PI state.

When that owner exits, exit_pi_state_list() uses the saved key to find the
hash bucket and acquires a reference to the waiter's private hash. If the
last user of the waiter's mm exits concurrently, futex_hash_free() frees
the hash while the owner still uses its bucket and reference.

Prevent this by validating in attach_to_pi_owner() that, for private
futexes, the owner mm and waiter mm are the same. Perform the check with
the owner's pi_lock held and after validating owner::futex::state to
serialize against a concurrent PI-state exit cleanup.

[ tglx: Amended comment ]

Fixes: 80367ad01d93 ("futex: Add basic infrastructure for local task local hash")
Signed-off-by: Kyle Zeng <kylebot@openai.com>
Signed-off-by: Thomas Gleixner <tglx@kernel.org>
Acked-by: Peter Zijlstra <peterz@infradead.org>
Assisted-by: Codex:gpt-5.6-sol
Cc: stable@vger.kernel.org

diff --git a/kernel/futex/pi.c b/kernel/futex/pi.c
index 795011ea1202..3e277ef155cd 100644
--- a/kernel/futex/pi.c
+++ b/kernel/futex/pi.c
@@ -465,6 +465,26 @@ static int attach_to_pi_owner(u32 __user *uaddr, u32 uval, union futex_key *key,
 		return ret;
 	}
 
+	/*
+	 * If the owner is about to exit() or exec() and tries to modify
+	 * p::futex::exit_state it is serialized against this code by
+	 * p::pi_lock.
+	 */
+	if (IS_ENABLED(CONFIG_MMU) && futex_key_is_private(key)) {
+		/*
+		 * A private futex key holds a pointer to the waiter's mm
+		 * without holding a reference on it. So it must not be attached
+		 * to an owner in a different address space. Otherwise that
+		 * owner's exit cleanup could access the private hash after the
+		 * key's mm is freed.
+		 */
+		if (unlikely(p->mm != key->private.mm)) {
+			raw_spin_unlock_irq(&p->pi_lock);
+			put_task_struct(p);
+			return -EPERM;
+		}
+	}
+
 	__attach_to_pi_owner(p, key, ps);
 	raw_spin_unlock_irq(&p->pi_lock);
 


             reply	other threads:[~2026-08-24 10:56 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-24 10:56 gregkh [this message]
2026-08-25 12:48 ` [patch 7.1.y 0/6] futex: Stable backports for recent issues Thomas Gleixner
2026-08-25 12:48   ` [patch 7.1.y 1/6] futex/pi: Reject cross-mm private futex owners Thomas Gleixner
2026-08-25 12:48   ` [patch 7.1.y 2/6] futex: Sanitize and document task_struct::futex::state transitions Thomas Gleixner
2026-08-25 12:48   ` [patch 7.1.y 3/6] futex/pi: Plug private futex exec() race Thomas Gleixner
2026-08-25 12:48   ` [patch 7.1.y 4/6] futex: Fix race in futex_pivot_pending() during private hash resize Thomas Gleixner
2026-08-25 12:48   ` [patch 7.1.y 5/6] futex: Fix race on the initial mm->futex.phash.ref allocation Thomas Gleixner
2026-08-25 12:48   ` [patch 7.1.y 6/6] futex: Fix might_sleep() warning in futex_pivot_pending() Thomas Gleixner
2026-08-25 12:59   ` [patch 7.1.y 0/6] futex: Stable backports for recent issues Greg KH

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=2026082446-lumpish-subdivide-9766@gregkh \
    --to=gregkh@linuxfoundation.org \
    --cc=kylebot@openai.com \
    --cc=peterz@infradead.org \
    --cc=stable@vger.kernel.org \
    --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