linux-kernel - [tip: locking/core] futex: Don't include process MM in futex key on no-MMU

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Fri, 27 Oct 2023 09:57:23 -0000
From:   "tip-bot2 for Ben Wolsieffer" <tip-bot2@...utronix.de>
To:     linux-tip-commits@...r.kernel.org
Cc:     Ben Wolsieffer <ben.wolsieffer@...ring.com>,
        Ingo Molnar <mingo@...nel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Darren Hart <dvhart@...radead.org>,
        Davidlohr Bueso <dave@...olabs.net>, andrealmeid@...lia.com,
        x86@...nel.org, linux-kernel@...r.kernel.org
Subject: [tip: locking/core] futex: Don't include process MM in futex key on no-MMU

The following commit has been merged into the locking/core branch of tip:

Commit-ID:     c73801ae4f22b390228ebf471d55668e824198b6
Gitweb:        https://git.kernel.org/tip/c73801ae4f22b390228ebf471d55668e824198b6
Author:        Ben Wolsieffer <ben.wolsieffer@...ring.com>
AuthorDate:    Thu, 19 Oct 2023 16:45:49 -04:00
Committer:     Ingo Molnar <mingo@...nel.org>
CommitterDate: Fri, 27 Oct 2023 11:53:42 +02:00

futex: Don't include process MM in futex key on no-MMU

On no-MMU, all futexes are treated as private because there is no need
to map a virtual address to physical to match the futex across
processes. This doesn't quite work though, because private futexes
include the current process's mm_struct as part of their key. This makes
it impossible for one process to wake up a shared futex being waited on
in another process.

Fix this bug by excluding the mm_struct from the key. With
a single address space, the futex address is already a unique key.

Fixes: 784bdf3bb694 ("futex: Assume all mappings are private on !MMU systems")
Signed-off-by: Ben Wolsieffer <ben.wolsieffer@...ring.com>
Signed-off-by: Ingo Molnar <mingo@...nel.org>
Acked-by: Peter Zijlstra <peterz@...radead.org>
Cc: Thomas Gleixner <tglx@...utronix.de>
Cc: Darren Hart <dvhart@...radead.org>
Cc: Davidlohr Bueso <dave@...olabs.net>
Cc: André Almeida <andrealmeid@...lia.com>
Link: https://lore.kernel.org/r/20231019204548.1236437-2-ben.wolsieffer@hefring.com
---
 kernel/futex/core.c | 12 +++++++++++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/kernel/futex/core.c b/kernel/futex/core.c
index ade7c73..52695c5 100644
--- a/kernel/futex/core.c
+++ b/kernel/futex/core.c
@@ -252,7 +252,17 @@ int get_futex_key(u32 __user *uaddr, unsigned int flags, union futex_key *key,
 	 *        but access_ok() should be faster than find_vma()
 	 */
 	if (!fshared) {
-		key->private.mm = mm;
+		/*
+		 * On no-MMU, shared futexes are treated as private, therefore
+		 * we must not include the current process in the key. Since
+		 * there is only one address space, the address is a unique key
+		 * on its own.
+		 */
+		if (IS_ENABLED(CONFIG_MMU))
+			key->private.mm = mm;
+		else
+			key->private.mm = NULL;
+
 		key->private.address = address;
 		return 0;
 	}