summaryrefslogtreecommitdiffstats
path: root/arch/frv
diff options
context:
space:
mode:
authorKees Cook <keescook@chromium.org>2017-04-05 09:39:08 -0700
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>2017-04-21 09:32:42 +0200
commitb1bfb5083bfa79d1400009ac6265bfb5f2c09ec9 (patch)
tree7647a491b84bebd502d865db623bd6811c0df3c9 /arch/frv
parent2c4d8f20cc2913d0ab738a491c3d26e09871e701 (diff)
downloadlinux-stable-b1bfb5083bfa79d1400009ac6265bfb5f2c09ec9.tar.gz
linux-stable-b1bfb5083bfa79d1400009ac6265bfb5f2c09ec9.tar.bz2
linux-stable-b1bfb5083bfa79d1400009ac6265bfb5f2c09ec9.zip
mm: Tighten x86 /dev/mem with zeroing reads
commit a4866aa812518ed1a37d8ea0c881dc946409de94 upstream. Under CONFIG_STRICT_DEVMEM, reading System RAM through /dev/mem is disallowed. However, on x86, the first 1MB was always allowed for BIOS and similar things, regardless of it actually being System RAM. It was possible for heap to end up getting allocated in low 1MB RAM, and then read by things like x86info or dd, which would trip hardened usercopy: usercopy: kernel memory exposure attempt detected from ffff880000090000 (dma-kmalloc-256) (4096 bytes) This changes the x86 exception for the low 1MB by reading back zeros for System RAM areas instead of blindly allowing them. More work is needed to extend this to mmap, but currently mmap doesn't go through usercopy, so hardened usercopy won't Oops the kernel. Reported-by: Tommi Rantala <tommi.t.rantala@nokia.com> Tested-by: Tommi Rantala <tommi.t.rantala@nokia.com> Signed-off-by: Kees Cook <keescook@chromium.org> Cc: Brad Spengler <spender@grsecurity.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Diffstat (limited to 'arch/frv')
0 files changed, 0 insertions, 0 deletions