[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <20190215174712.372898450@goodmis.org>
Date: Fri, 15 Feb 2019 12:47:12 -0500
From: Steven Rostedt <rostedt@...dmis.org>
To: linux-kernel@...r.kernel.org
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
Ingo Molnar <mingo@...nel.org>,
Andrew Morton <akpm@...ux-foundation.org>
Subject: [PATCH 0/2 v2] [GIT PULL (take two)] tracing: Two more fixes
Linus,
Two more tracing fixes
- Have kprobes not use copy_from_user() to access kernel addresses,
because kprobes can legitimately poke at bad kernel memory, which
will fault. Copy from user code should never fault in kernel space.
Using probe_mem_read() can handle kernel address space faulting.
- Put back the entries counter in the tracing output that was accidentally
removed.
Please pull the latest trace-v5.0-rc4-3 tree, which can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace.git
trace-v5.0-rc4-3
Tag SHA1: 633d24cef06bed019a34e84ff82c20782449ee5c
Head SHA1: 9e7382153f80ba45a0bbcd540fb77d4b15f6e966
Changbin Du (1):
kprobe: Do not use uaccess functions to access kernel memory that can fault
Quentin Perret (1):
tracing: Fix number of entries in trace header
----
kernel/trace/trace.c | 2 ++
kernel/trace/trace_kprobe.c | 10 +---------
2 files changed, 3 insertions(+), 9 deletions(-)
Changes from v1:
- Explain that the kprobe change to probe_mem_read() is because
copy_from_user() can not handle bad memory in kernel space,
which kprobes can cause. The code itself is unchanged.
I tweaked the change log of that patch to clarify that as well.
Powered by blists - more mailing lists