linux-kernel - [tip: perf/core] uprobes: document the usage of mm->mmap

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]

Message-ID: <172285896599.2215.2455695217344541134.tip-bot2@tip-bot2>
Date: Mon, 05 Aug 2024 11:56:05 -0000
From: "tip-bot2 for Oleg Nesterov" <tip-bot2@...utronix.de>
To: linux-tip-commits@...r.kernel.org
Cc: Andrii Nakryiko <andrii@...nel.org>, Oleg Nesterov <oleg@...hat.com>,
 "Peter Zijlstra (Intel)" <peterz@...radead.org>, Jiri Olsa <jolsa@...nel.org>,
 "Masami Hiramatsu (Google)" <mhiramat@...nel.org>, x86@...nel.org,
 linux-kernel@...r.kernel.org
Subject: [tip: perf/core] uprobes: document the usage of mm->mmap_lock

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

Commit-ID:     84455e6923c79a37812930787aaa141e82afe315
Gitweb:        https://git.kernel.org/tip/84455e6923c79a37812930787aaa141e82afe315
Author:        Oleg Nesterov <oleg@...hat.com>
AuthorDate:    Thu, 01 Aug 2024 15:27:09 +02:00
Committer:     Peter Zijlstra <peterz@...radead.org>
CommitterDate: Fri, 02 Aug 2024 11:30:30 +02:00

uprobes: document the usage of mm->mmap_lock

The comment above uprobe_write_opcode() is wrong, unapply_uprobe() calls
it under mmap_read_lock() and this is correct.

And it is completely unclear why register_for_each_vma() takes mmap_lock
for writing, add a comment to explain that mmap_write_lock() is needed to
avoid the following race:

	- A task T hits the bp installed by uprobe and calls
	  find_active_uprobe()

	- uprobe_unregister() removes this uprobe/bp

	- T calls find_uprobe() which returns NULL

	- another uprobe_register() installs the bp at the same address

	- T calls is_trap_at_addr() which returns true

	- T returns to handle_swbp() and gets SIGTRAP.

Reported-by: Andrii Nakryiko <andrii@...nel.org>
Signed-off-by: Oleg Nesterov <oleg@...hat.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@...radead.org>
Reviewed-by: Jiri Olsa <jolsa@...nel.org>
Acked-by: Andrii Nakryiko <andrii@...nel.org>
Acked-by: "Masami Hiramatsu (Google)" <mhiramat@...nel.org>
Link: https://lore.kernel.org/r/20240801132709.GA8780@redhat.com
---
 kernel/events/uprobes.c | 10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
index f69ecd3..2d1457e 100644
--- a/kernel/events/uprobes.c
+++ b/kernel/events/uprobes.c
@@ -453,7 +453,7 @@ static int update_ref_ctr(struct uprobe *uprobe, struct mm_struct *mm,
  * @vaddr: the virtual address to store the opcode.
  * @opcode: opcode to be written at @vaddr.
  *
- * Called with mm->mmap_lock held for write.
+ * Called with mm->mmap_lock held for read or write.
  * Return 0 (success) or a negative errno.
  */
 int uprobe_write_opcode(struct arch_uprobe *auprobe, struct mm_struct *mm,
@@ -1046,7 +1046,13 @@ register_for_each_vma(struct uprobe *uprobe, struct uprobe_consumer *new)
 
 		if (err && is_register)
 			goto free;
-
+		/*
+		 * We take mmap_lock for writing to avoid the race with
+		 * find_active_uprobe() which takes mmap_lock for reading.
+		 * Thus this install_breakpoint() can not make
+		 * is_trap_at_addr() true right after find_uprobe()
+		 * returns NULL in find_active_uprobe().
+		 */
 		mmap_write_lock(mm);
 		vma = find_vma(mm, info->vaddr);
 		if (!vma || !valid_vma(vma, is_register) ||