From: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
To: Kees Cook <keescook@chromium.org>
Cc: William Cohen <wcohen@redhat.com>,
stable@vger.kernel.org, Laura Abbott <labbott@redhat.com>,
Masami Hiramatsu <mhiramat@kernel.org>,
Russell King <rmk+kernel@armlinux.org.uk>,
linux-kernel <linux-kernel@vger.kernel.org>,
lttng@reliableembeddedsystems.com,
lttng-dev <lttng-dev@lists.lttng.org>
Subject: BUG: optimized kprobes illegal instructions in v4.19 stable kernels
Date: Mon, 4 Feb 2019 14:15:21 -0500 (EST) [thread overview]
Message-ID: <342740659.2887.1549307721609.JavaMail.zimbra@efficios.com> (raw)
Hi,
I notice this commit as a possible culprit of the illegal instructions my lttng
users are noticing on arm32 when using kprobes on a v4.19.13 Linux kernel
in a Yocto environment [1]. They were able to reproduce the issue with perf
as well.
commit e46daee53bb50bde38805f1823a182979724c229
Author: Kees Cook <keescook@chromium.org>
Date: Tue Oct 30 22:12:56 2018 +0100
ARM: 8806/1: kprobes: Fix false positive with FORTIFY_SOURCE
I *think* the intent there was to do
- memcpy(code, &optprobe_template_entry,
+ memcpy(code, (unsigned long *)&optprobe_template_entry,
But if you look at the commit, the "&" seems to have been stripped away,
which happens to change the behavior significantly.
Has this change ever been runtime-tested ?
It has been backported to:
- 4.19 stable as commit 3fe0c68aea21
- 4.14 stable as commit f9e0bc710347
Thanks,
Mathieu
[1] https://bugs.lttng.org/issues/1174
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
next reply other threads:[~2019-02-04 19:15 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-04 19:15 Mathieu Desnoyers [this message]
2019-02-05 15:06 ` BUG: optimized kprobes illegal instructions in v4.19 stable kernels Kees Cook
2019-02-06 4:41 ` Masami Hiramatsu
2019-02-18 12:26 ` Greg KH
2019-02-18 14:11 ` Masami Hiramatsu
2019-02-18 14:55 ` Mathieu Desnoyers
2019-02-21 20:02 ` Mathieu Desnoyers
2019-02-22 0:10 ` Russell King - ARM Linux admin
2019-02-22 0:17 ` Mathieu Desnoyers
2019-02-22 6:25 ` Greg Kroah-Hartman
2019-02-22 8:29 ` Greg Kroah-Hartman
2019-02-22 20:18 ` Mathieu Desnoyers
2019-02-06 11:48 ` David Laight
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=342740659.2887.1549307721609.JavaMail.zimbra@efficios.com \
--to=mathieu.desnoyers@efficios.com \
--cc=keescook@chromium.org \
--cc=labbott@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lttng-dev@lists.lttng.org \
--cc=lttng@reliableembeddedsystems.com \
--cc=mhiramat@kernel.org \
--cc=rmk+kernel@armlinux.org.uk \
--cc=stable@vger.kernel.org \
--cc=wcohen@redhat.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.