linux-kernel - [RFC][PATCH 0/4] tracing/kprobes/uprobes: Fix race between opening probe event files and deleting probe

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-next>] [day] [month] [year] [list]

Date:	Wed, 03 Jul 2013 23:33:47 -0400
From:	Steven Rostedt <rostedt@...dmis.org>
To:	linux-kernel@...r.kernel.org
Cc:	Oleg Nesterov <oleg@...hat.com>,
	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>,
	"zhangwei(Jovi)" <jovi.zhangwei@...wei.com>,
	Jiri Olsa <jolsa@...hat.com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Arnaldo Carvalho de Melo <acme@...stprotocols.net>,
	Srikar Dronamraju <srikar@...ux.vnet.ibm.com>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Ingo Molnar <mingo@...hat.com>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: [RFC][PATCH 0/4] tracing/kprobes/uprobes: Fix race between opening probe event files and deleting probe


Currently there exists a race with deleting a kprobe or uprobe and
a user opening the probe event file or using perf events.

The problem stems from not being able to take the probe_lock from the
unregister code because we may have the event_mutex at the time, and
the event mutex may be taken with the probe_lock held.

To solve this, the events get a ref count (using the flags field), where
when an event file is opened, the ftrace_event_call ref count increments.
Then this is checked under event_mutex and if set, the unregistering
of the probe will fail.

Here's a test that shows how things break:

     # cd /sys/kernel/debug/tracing
     # echo 'p:sigprocmask sigprocmask' > kprobe_events || exit -1
     # enable_probe() {
        sleep 10
        echo 1
     }
     # file=events/kprobes/sigprocmask/enable
     # enable_probe > $file &
     > kprobe_events
    
    The above will corrupt the kprobe system, as the write to the enable
    file will happen after the kprobe was deleted.
    
    Trying to create the probe again fails:
    
     # echo 'p:sigprocmask sigprocmask' > kprobe_events
     # cat kprobe_events
    p:kprobes/sigprocmask sigprocmask
     # ls events/kprobes/
    enable  filter

After applying these patches, the "> kprobe_events" fails due to the
event being busy.

Masami, please review these patches and give your ack.

Srikar, can you please review the last patch. I didn't test uprobes
with this. I'll do that after the 4th.

Thanks,

-- Steve


Oleg Nesterov (1):
      tracing: trace_remove_event_call() should fail if call/file is in use

Steven Rostedt (Red Hat) (3):
      tracing: Add ref count to ftrace_event_call
      tracing/kprobes: Fail to unregister if probe event files are open
      tracing/uprobes: Fail to unregister if probe event files are open

----
 include/linux/ftrace_event.h |    8 +++-
 kernel/trace/trace_events.c  |  109 +++++++++++++++++++++++++++++++++++++++---
 kernel/trace/trace_kprobe.c  |   21 +++++---
 kernel/trace/trace_uprobe.c  |   48 ++++++++++++++-----
 4 files changed, 160 insertions(+), 26 deletions(-)

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/