linux-kernel - Re: [PATCH v5 tip/perf/core 1/2] uprobes: simplify find_active_uprobe

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20241127080133.GA7717@redhat.com>
Date: Wed, 27 Nov 2024 09:01:56 +0100
From: Oleg Nesterov <oleg@...hat.com>
To: Jann Horn <jannh@...gle.com>
Cc: Andrii Nakryiko <andrii@...nel.org>, linux-trace-kernel@...r.kernel.org,
	linux-mm@...ck.org, akpm@...ux-foundation.org, peterz@...radead.org,
	mingo@...nel.org, torvalds@...ux-foundation.org,
	rostedt@...dmis.org, mhiramat@...nel.org, bpf@...r.kernel.org,
	linux-kernel@...r.kernel.org, jolsa@...nel.org, paulmck@...nel.org,
	willy@...radead.org, surenb@...gle.com, mjguzik@...il.com,
	brauner@...nel.org, mhocko@...nel.org, vbabka@...e.cz,
	shakeel.butt@...ux.dev, hannes@...xchg.org,
	lorenzo.stoakes@...cle.com, Liam.Howlett@...cle.com,
	david@...hat.com, arnd@...db.de, viro@...iv.linux.org.uk,
	hca@...ux.ibm.com
Subject: Re: [PATCH v5 tip/perf/core 1/2] uprobes: simplify
 find_active_uprobe_rcu() VMA checks

On 11/26, Jann Horn wrote:
>
> On Fri, Nov 22, 2024 at 4:59 AM Andrii Nakryiko <andrii@...nel.org> wrote:
> > At the point where find_active_uprobe_rcu() is used we know that VMA in
> > question has triggered software breakpoint, so we don't need to validate
> > vma->vm_flags. Keep only vma->vm_file NULL check.
>
> How do we know that the VMA we find triggered a software breakpoint?
> Between the time a software breakpoint was hit and the time we took
> the mmap_read_lock(), the VMA could have been replaced with an
> entirely different one, right?

Right, but this doesn't really differ from the case when another thread
replaces (or even unmaps) this VMA after find_active_uprobe_rcu() drops
mm->mmap_lock and returns a found uprobe.

So I think this is fine.

Oleg.