Bugzilla – Bug 904012
VUL-0: CVE-2014-7825: kernel: OOB read in perf
Last modified: 2017-09-20 14:52:49 UTC
Created attachment 612477 [details] PoC Date: Mon, 3 Nov 2014 22:20:10 +0100 From: Robert Święcki <robert@swiecki.net> To: linux-distros@vs.openwall.org 1. Perf OOB read - can be used to defeat kASLR IMO - perf.c as a PoC attached The upper bound of the syscall nr is not checked against the limit http://lxr.free-electrons.com/source/kernel/trace/trace_syscalls.c#L569 and it leads to oob here (as well as in perf_syscall_exit) http://lxr.free-electrons.com/source/kernel/trace/trace_syscalls.c#L572 Probably cannot be used for anything else (except with annoying the system admin with scary dmesg messages) than finding layout of the kernel running on the system =================== Currently there is no decision on the CRD date, maybe it will be release quite quickly since the patch is public. Only the information about the possible exploitation is private. I checked in SLE 12 kernel and it looks like we're vulnerable.
bugbot adjusting priority
1. Perf subsystem oob read in supervisor mode (local DoS) - CVE-2014-7825 ===================================================================== The syscall_nr variable is not verified against the upper limit (NR_syscalls) in the perf_syscall_enter()/perf_syscall_exit() functions, making it possible for the subsequent test_bit() function to fail when trying to access non-present memory pages. http://lxr.free-electrons.com/source/kernel/trace/trace_syscalls.c?v=3.16#L569 The impact of this bug depends on the value of kernel.panic_on_oops sysctl. When equal to 1, it becomes local DoS. For other values it can still aid an attacker with mapping the kernel address space layout under systems with kASLR enabled. This issue has been fixed with in the kernel's mainline tree with: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/kernel/trace/trace_syscalls.c?id=086ba77a6db00ed858ff07451bedee197df868c9 Author: Rabin Vincent <rabin@rab.in> Date: Wed Oct 29 23:06:58 2014 +0100
will this be included in our kernel git branches?
(In reply to Johannes Segitz from comment #6) > will this be included in our kernel git branches? Sorry, I forgot to close this. Fix is already in all necessary branches via bnc#904013.