From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754527AbdGNPIa (ORCPT ); Fri, 14 Jul 2017 11:08:30 -0400 Received: from mail.efficios.com ([167.114.142.141]:33809 "EHLO mail.efficios.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754176AbdGNPI2 (ORCPT ); Fri, 14 Jul 2017 11:08:28 -0400 X-Greylist: delayed 533 seconds by postgrey-1.27 at vger.kernel.org; Fri, 14 Jul 2017 11:08:28 EDT From: Francis Deslauriers To: rostedt@goodmis.org, mhiramat@kernel.org, peterz@infradead.org Cc: mathieu.desnoyers@efficios.com, linux-kernel@vger.kernel.org, Francis Deslauriers Subject: [PATCH 0/2] kprobe: Fix: add symbols to kprobe blacklist Date: Fri, 14 Jul 2017 10:58:33 -0400 Message-Id: <1500044315-9508-1-git-send-email-francis.deslauriers@efficios.com> X-Mailer: git-send-email 2.7.4 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi all, While fuzzing the Perf kprobe and kretprobe interfaces, I found some inputs that trigger crashes of a 4.12 kernel(6f7da290413ba713f0cdd9ff1a2a9bb129ef4f6c) on a x86-64 VM. I know that K(ret)probes can crash the kernel in multiple ways but should Perf be allowed to do it? To do this analysis, I used the symbols reported by /proc/kallsyms in conjonction with the Perf debugfs interface. Using this technique, I was able to find two instrumentation configurations that could crash the kernel. I am suggesting changes that fixed both issues for me by blacklisting the symbols in question. Kprobe on apic_timer_interrupt: I believe that this is caused by the fact that kprobe adds a INT3 in a apic interrupt routine. How to reproduce: echo 'p:event1 apic_timer_interrupt ' > kprobe_events Crash log:[1] This can be fixed by blacklisting the apicinterrupt3 symbols directly in the assembly macro. See patch[1/2]. I am not sure that blacklisting all apicinterrupt symbols is the right solution. Kretprobe on ftrace_ops_assist_func and another function: Those crashes are triggered when hooking a kretprobe on the ftrace_ops_assist_func symbol and some other functions to make the this first function reacheable. From my understanding, ftrace_ops_assist_func is the function called directly when the kprobe is hit. Thus it should be marked with NOKPROBE_SYMBOL. Here are some configurations that can easily reproduce this bug. Those other functions are called during the fork of a process so they are easy to control. Enable the following kprobes and launch a process to trigger a fork to see the kernel crash. Conf #1 echo 'r:event1 ftrace_ops_assist_func' > kprobe_events echo 'r:event2 clear_all_latency_tracing' > kprobe_events Crash log:[2] Conf #2 echo 'r:event1 ftrace_ops_assist_func' > kprobe_events echo 'r:event2 acct_clear_integrals' > kprobe_events Crash log:[3] Conf #3 echo 'r:event1 ftrace_ops_assist_func' > kprobe_events echo 'r:event2 arch_dup_task_struct' > kprobe_events Crash log:[4] The ftrace_ops_assist_func should be included in the kprobe blacklist using NOKPROBE_SYMBOL. See patch [2/2]. Since those were found using fuzzing, it's not an exhaustive analysis. Here is the .config I am using[5]. Thanks, Francis Deslauriers EfficiOS inc. [1]: https://pastebin.com/Mpp9Yzqb [2]: https://pastebin.com/CtsfzUwG [3]: https://pastebin.com/txxuJXrz [4]: https://pastebin.com/8qrJvzD3 [5]: https://pastebin.com/x5q0sgyK Francis Deslauriers (2): kprobe: fix: Add _ASM_NOKPROBE to x86 apic interrupt macro kprobe: fix: Add ftrace_ops_assist_func to kprobe blacklist arch/x86/entry/entry_64.S | 1 + kernel/trace/ftrace.c | 2 ++ 2 files changed, 3 insertions(+) -- 2.7.4