]> git.ipfire.org Git - thirdparty/kernel/stable.git/commit
perf/core: Fix perf_event_open() vs. execve() race
authorPeter Zijlstra <peterz@infradead.org>
Tue, 26 Apr 2016 09:36:53 +0000 (11:36 +0200)
committerBen Hutchings <ben@decadent.org.uk>
Thu, 2 May 2019 20:42:04 +0000 (21:42 +0100)
commit92cb82fec63d558f7eecc97afbbbdf3fe5ef95b5
treee5ab972c08f52ce0d77618b732cedefa129282ab
parenta301e6a651037c11d2d9932a35fb56a04eedba8c
perf/core: Fix perf_event_open() vs. execve() race

commit 79c9ce57eb2d5f1497546a3946b4ae21b6fdc438 upstream.

Jann reported that the ptrace_may_access() check in
find_lively_task_by_vpid() is racy against exec().

Specifically:

  perf_event_open() execve()

  ptrace_may_access()
commit_creds()
  ... if (get_dumpable() != SUID_DUMP_USER)
  perf_event_exit_task();
  perf_install_in_context()

would result in installing a counter across the creds boundary.

Fix this by wrapping lots of perf_event_open() in cred_guard_mutex.
This should be fine as perf_event_exit_task() is already called with
cred_guard_mutex held, so all perf locks already nest inside it.

Reported-by: Jann Horn <jannh@google.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Stephane Eranian <eranian@google.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Vince Weaver <vincent.weaver@maine.edu>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
[bwh: Backported to 3.16:
 - Update another failure path in perf_event_open()
 - Adjust context]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
kernel/events/core.c