From: Masami Hiramatsu <mhiramat@kernel.org>
To: Ingo Molnar <mingo@redhat.com>
Cc: Masami Hiramatsu <mhiramat@kernel.org>,
linux-kernel@vger.kernel.org,
Peter Zijlstra <peterz@infradead.org>,
Ananth N Mavinakayanahalli <ananth@linux.vnet.ibm.com>,
Thomas Gleixner <tglx@linutronix.de>,
"H . Peter Anvin" <hpa@zytor.com>, Jon Medhurst <tixy@linaro.org>,
Wang Nan <wangnan0@huawei.com>,
Russell King <linux@armlinux.org.uk>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will.deacon@arm.com>,
"David A . Long" <dave.long@linaro.org>,
Sandeepa Prabhu <sandeepa.s.prabhu@gmail.com>
Subject: [BUGFIX PATCH tip/master 0/3] kprobes: Fix a possible deadlock in kretprobe
Date: Wed, 8 Feb 2017 00:10:52 +0900 [thread overview]
Message-ID: <148648024215.30949.11929183640906306731.stgit@devbox> (raw)
Hi,
This series will fix a possible deadlock case in kretprobe
on x86, arm, arm64. Since kretprobe has been optimized on
those arch, they have similar possible deadlock issue.
Problem
=====
The deadlock senario is when a user puts 2 kretprobes,
one on normal function and one on a function which can be
called from NMI or FIQ where normal interrupt disabled.
(we don't recommend it, but possible.) In this case, if
the kernel hits the 1st kretprobe on a normal function
return which calls trampoline_handler(), acquire a
spinlock on the hash table in kretprobe_hash_lock() and
disable irqs.
After that, if NMI(or FIQ on arm/arm64) is occurred and
the 2nd kretprobe is kicked, it also calls
trampoline_handler() and tries to acquire the same
spinlock (since the hash is based on current task, same
as the 1st kretprobe), it causes a deadlock on the
spinlock.
Note that this is very rare case, but theoretically happens.
Reason and Affected Arch
=====
Actually, this bug has been introduced by kretprobe-booster,
which removes a kprobe from return trampoline code, but also
resets current kprobe, which can be a stopper for the nested
k(ret)probes. So, currently only x86, arm, and arm64 are
affected, because other arch have not implemented the
kretprobe-booster.
Solution
=====
To fix this issue, I introduced a dummy kprobe which is set
as a current kprobe while holding the kretprobe-hash lock.
With that, if an NMI/FIQ occurred and 2nd kretprobe's kprobe
is kicked (to modify the return address, a kprobe is kicked
when the target function is called), the kprobe (and the 2nd
kretprobe also) is skipped because it detects there is
another kprobe is running.
This reentrance detection and nested kprobe blocker had
existed when the original kretprobe was implemented by
using kprobe on trampoline code. This fix just revived it.
Thank you,
---
Masami Hiramatsu (3):
kprobes/x86: Fix a possible deadlock case in kretprobe
kprobes/arm64: Fix a possible deadlock case in kretprobe
kprobes/arm: Fix a possible deadlock case in kretprobe
arch/arm/probes/kprobes/core.c | 12 ++++++++++--
arch/arm64/kernel/probes/kprobes.c | 12 ++++++++++--
arch/x86/kernel/kprobes/core.c | 13 ++++++++++---
3 files changed, 30 insertions(+), 7 deletions(-)
--
Masami Hiramatsu
next reply other threads:[~2017-02-07 15:11 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-07 15:10 Masami Hiramatsu [this message]
2017-02-07 15:12 ` [BUGFIX PATCH tip/master 1/3] kprobes/x86: Fix a possible deadlock case in kretprobe Masami Hiramatsu
2017-02-07 15:13 ` [BUGFIX PATCH tip/master 2/3] kprobes/arm64: " Masami Hiramatsu
2017-02-08 15:06 ` Will Deacon
2017-02-08 21:45 ` Masami Hiramatsu
2017-02-07 15:14 ` [BUGFIX PATCH tip/master 3/3] kprobes/arm: " Masami Hiramatsu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=148648024215.30949.11929183640906306731.stgit@devbox \
--to=mhiramat@kernel.org \
--cc=ananth@linux.vnet.ibm.com \
--cc=catalin.marinas@arm.com \
--cc=dave.long@linaro.org \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=sandeepa.s.prabhu@gmail.com \
--cc=tglx@linutronix.de \
--cc=tixy@linaro.org \
--cc=wangnan0@huawei.com \
--cc=will.deacon@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox