linux-stable.git/arch, branch v4.9.31

x86/boot: Use CROSS_COMPILE prefix for readelf

2017-06-07T10:07:49+00:00

commit 3780578761921f094179c6289072a74b2228c602 upstream.

The boot code Makefile contains a straight 'readelf' invocation. This
causes build warnings in cross compile environments, when there is no
unprefixed readelf accessible via $PATH.

Add the missing $(CROSS_COMPILE) prefix.

[ tglx: Rewrote changelog ]

Fixes: 98f78525371b ("x86/boot: Refuse to build with data relocations")
Signed-off-by: Rob Landley 
Acked-by: Kees Cook 
Cc: Jiri Kosina 
Cc: Paul Bolle 
Cc: "H.J. Lu" 
Link: http://lkml.kernel.org/r/ced18878-693a-9576-a024-113ef39a22c0@landley.net
Signed-off-by: Thomas Gleixner 
Signed-off-by: Greg Kroah-Hartman

x86/MCE: Export memory_error()

2017-06-07T10:07:47+00:00

commit 2d1f406139ec20320bf38bcd2461aa8e358084b5 upstream.

Export the function which checks whether an MCE is a memory error to
other users so that we can reuse the logic. Drop the boot_cpu_data use,
while at it, as mce.cpuvendor already has the CPU vendor in there.

Integrate a piece from a patch from Vishal Verma
 to export it for modules (nfit).

The main reason we're exporting it is that the nfit handler
nfit_handle_mce() needs to detect a memory error properly before doing
its recovery actions.

Signed-off-by: Borislav Petkov 
Cc: Tony Luck 
Cc: Vishal Verma 
Link: http://lkml.kernel.org/r/20170519093915.15413-2-bp@alien8.de
Signed-off-by: Thomas Gleixner 
Signed-off-by: Greg Kroah-Hartman

powerpc/spufs: Fix hash faults for kernel regions

2017-06-07T10:07:46+00:00

commit d75e4919cc0b6fbcbc8d6654ef66d87a9dbf1526 upstream.

Commit ac29c64089b7 ("powerpc/mm: Replace _PAGE_USER with
_PAGE_PRIVILEGED") swapped _PAGE_USER for _PAGE_PRIVILEGED, and
introduced check_pte_access() which denied kernel access to
non-_PAGE_PRIVILEGED pages.

However, it didn't add _PAGE_PRIVILEGED to the hash fault handler
for spufs' kernel accesses, so the DMAs required to establish SPE
memory no longer work.

This change adds _PAGE_PRIVILEGED to the hash fault handler for
kernel accesses.

Fixes: ac29c64089b7 ("powerpc/mm: Replace _PAGE_USER with _PAGE_PRIVILEGED")
Signed-off-by: Jeremy Kerr 
Reported-by: Sombat Tragolgosol 
Reviewed-by: Aneesh Kumar K.V 
Signed-off-by: Michael Ellerman 
Signed-off-by: Greg Kroah-Hartman

sparc/ftrace: Fix ftrace graph time measurement

2017-06-07T10:07:46+00:00

[ Upstream commit 48078d2dac0a26f84f5f3ec704f24f7c832cce14 ]

The ftrace function_graph time measurements of a given function is not
accurate according to those recorded by ftrace using the function
filters.  This change pulls the x86_64 fix from 'commit 722b3c746953
("ftrace/graph: Trace function entry before updating index")' into the
sparc specific prepare_ftrace_return which stops ftrace from
counting interrupted tasks in the time measurement.

Example measurements for select_task_rq_fair running "hackbench 100
process 1000":

              |  tracing/trace_stat/function0  |  function_graph
 Before patch |  2.802 us                      |  4.255 us
 After patch  |  2.749 us                      |  3.094 us

Signed-off-by: Liam R. Howlett 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

sparc: Fix -Wstringop-overflow warning

2017-06-07T10:07:46+00:00

[ Upstream commit deba804c90642c8ed0f15ac1083663976d578f54 ]

Greetings,

GCC 7 introduced the -Wstringop-overflow flag to detect buffer overflows
in calls to string handling functions [1][2]. Due to the way
``empty_zero_page'' is declared in arch/sparc/include/setup.h, this
causes a warning to trigger at compile time in the function mem_init(),
which is subsequently converted to an error. The ensuing patch fixes
this issue and aligns the declaration of empty_zero_page to that of
other architectures. Thank you.

Cheers,
Orlando.

[1] https://gcc.gnu.org/ml/gcc-patches/2016-10/msg02308.html
[2] https://gcc.gnu.org/gcc-7/changes.html

Signed-off-by: Orlando Arias 

--------------------------------------------------------------------------------
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

bpf, arm64: fix faulty emission of map access in tail calls

2017-06-07T10:07:43+00:00

[ Upstream commit d8b54110ee944de522ccd3531191f39986ec20f9 ]

Shubham was recently asking on netdev why in arm64 JIT we don't multiply
the index for accessing the tail call map by 8. That led me into testing
out arm64 JIT wrt tail calls and it turned out I got a NULL pointer
dereference on the tail call.

The buggy access is at:

  prog = array->ptrs[index];
  if (prog == NULL)
      goto out;

  [...]
  00000060:  d2800e0a  mov x10, #0x70 // #112
  00000064:  f86a682a  ldr x10, [x1,x10]
  00000068:  f862694b  ldr x11, [x10,x2]
  0000006c:  b40000ab  cbz x11, 0x00000080
  [...]

The code triggering the crash is f862694b. x1 at the time contains the
address of the bpf array, x10 offsetof(struct bpf_array, ptrs). Meaning,
above we load the pointer to the program at map slot 0 into x10. x10
can then be NULL if the slot is not occupied, which we later on try to
access with a user given offset in x2 that is the map index.

Fix this by emitting the following instead:

  [...]
  00000060:  d2800e0a  mov x10, #0x70 // #112
  00000064:  8b0a002a  add x10, x1, x10
  00000068:  d37df04b  lsl x11, x2, #3
  0000006c:  f86b694b  ldr x11, [x10,x11]
  00000070:  b40000ab  cbz x11, 0x00000084
  [...]

This basically adds the offset to ptrs to the base address of the bpf
array we got and we later on access the map with an index * 8 offset
relative to that. The tail call map itself is basically one large area
with meta data at the head followed by the array of prog pointers.
This makes tail calls working again, tested on Cavium ThunderX ARMv8.

Fixes: ddb55992b04d ("arm64: bpf: implement bpf_tail_call() helper")
Reported-by: Shubham Bansal 
Signed-off-by: Daniel Borkmann 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

um: Fix to call read_initrd after init_bootmem

2017-05-25T13:44:47+00:00

commit 5b4236e17cc1bd9fa14b2b0c7a4ae632d41f2e20 upstream.

Since read_initrd() invokes alloc_bootmem() for allocating
memory to load initrd image, it must be called after init_bootmem.

This makes read_initrd() called directly from setup_arch()
after init_bootmem() and mem_total_pages().

Fixes: b63236972e1 ("um: Setup physical memory in setup_arch()")
Signed-off-by: Masami Hiramatsu 
Signed-off-by: Richard Weinberger 
Signed-off-by: Greg Kroah-Hartman

osf_wait4(): fix infoleak

2017-05-25T13:44:47+00:00

commit a8c39544a6eb2093c04afd5005b6192bd0e880c6 upstream.

failing sys_wait4() won't fill struct rusage...

Signed-off-by: Al Viro 
Signed-off-by: Greg Kroah-Hartman

MIPS: Loongson-3: Select MIPS_L1_CACHE_SHIFT_6

2017-05-25T13:44:47+00:00

commit 17c99d9421695a0e0de18bf1e7091d859e20ec1d upstream.

Some newer Loongson-3 have 64 bytes cache lines, so select
MIPS_L1_CACHE_SHIFT_6.

Signed-off-by: Huacai Chen 
Cc: John Crispin 
Cc: Steven J . Hill 
Cc: Fuxin Zhang 
Cc: Zhangjin Wu 
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/15755/
Signed-off-by: Ralf Baechle 
Signed-off-by: Greg Kroah-Hartman

metag/uaccess: Check access_ok in strncpy_from_user

2017-05-25T13:44:46+00:00

commit 3a158a62da0673db918b53ac1440845a5b64fd90 upstream.

The metag implementation of strncpy_from_user() doesn't validate the src
pointer, which could allow reading of arbitrary kernel memory. Add a
short access_ok() check to prevent that.

Its still possible for it to read across the user/kernel boundary, but
it will invariably reach a NUL character after only 9 bytes, leaking
only a static kernel address being loaded into D0Re0 at the beginning of
__start, which is acceptable for the immediate fix.

Reported-by: Al Viro 
Signed-off-by: James Hogan 
Cc: linux-metag@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman