maccess: always use strict semantics for probe_kernel_read
Except for historical confusion in the kprobes/uprobes and bpf tracers, which has been fixed now, there is no good reason to ever allow user memory accesses from probe_kernel_read. Switch probe_kernel_read to only read from kernel memory. [akpm@linux-foundation.org: update it for "mm, dump_page(): do not crash with invalid mapping pointer"] Signed-off-by:Christoph Hellwig <hch@lst.de> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Cc: Alexei Starovoitov <ast@kernel.org> Cc: Daniel Borkmann <daniel@iogearbox.net> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Ingo Molnar <mingo@elte.hu> Cc: Masami Hiramatsu <mhiramat@kernel.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/20200521152301.2587579-17-hch@lst.de Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
Showing
- arch/parisc/lib/memcpy.c 1 addition, 1 deletionarch/parisc/lib/memcpy.c
- arch/um/kernel/maccess.c 1 addition, 1 deletionarch/um/kernel/maccess.c
- arch/x86/mm/maccess.c 2 additions, 7 deletionsarch/x86/mm/maccess.c
- include/linux/uaccess.h 1 addition, 3 deletionsinclude/linux/uaccess.h
- kernel/trace/bpf_trace.c 1 addition, 1 deletionkernel/trace/bpf_trace.c
- kernel/trace/trace_kprobe.c 2 additions, 2 deletionskernel/trace/trace_kprobe.c
- mm/debug.c 5 additions, 5 deletionsmm/debug.c
- mm/maccess.c 6 additions, 34 deletionsmm/maccess.c
Loading
Please register or sign in to comment