linux-stable.git/arch, branch v3.18.31

arm64: errata: Add -mpc-relative-literal-loads to build flags

2016-04-18T12:49:41+00:00

[ Upstream commit 67dfa1751ce71e629aad7c438e1678ad41054677 ]

GCC6 (and Linaro's 2015.12 snapshot of GCC5) has a new default that uses
adrp/ldr or adrp/add to address literal pools. When CONFIG_ARM64_ERRATUM_843419
is enabled, modules built with this toolchain fail to load:

  module libahci: unsupported RELA relocation: 275

This patch fixes the problem by passing '-mpc-relative-literal-loads'
to the compiler.

Cc: stable@vger.kernel.org
Fixes: df057cc7b4fa ("arm64: errata: add module build workaround for erratum #843419")
BugLink: http://bugs.launchpad.net/bugs/1533009
Acked-by: Ard Biesheuvel 
Suggested-by: Christophe Lyon 
Signed-off-by: Dann Frazier 
Signed-off-by: Will Deacon 
Signed-off-by: Sasha Levin

fs/coredump: prevent fsuid=0 dumps into user-controlled directories

2016-04-18T12:49:38+00:00

[ Upstream commit 378c6520e7d29280f400ef2ceaf155c86f05a71a ]

This commit fixes the following security hole affecting systems where
all of the following conditions are fulfilled:

 - The fs.suid_dumpable sysctl is set to 2.
 - The kernel.core_pattern sysctl's value starts with "/". (Systems
   where kernel.core_pattern starts with "|/" are not affected.)
 - Unprivileged user namespace creation is permitted. (This is
   true on Linux >=3.8, but some distributions disallow it by
   default using a distro patch.)

Under these conditions, if a program executes under secure exec rules,
causing it to run with the SUID_DUMP_ROOT flag, then unshares its user
namespace, changes its root directory and crashes, the coredump will be
written using fsuid=0 and a path derived from kernel.core_pattern - but
this path is interpreted relative to the root directory of the process,
allowing the attacker to control where a coredump will be written with
root privileges.

To fix the security issue, always interpret core_pattern for dumps that
are written under SUID_DUMP_ROOT relative to the root directory of init.

Signed-off-by: Jann Horn 
Acked-by: Kees Cook 
Cc: Al Viro 
Cc: "Eric W. Biederman" 
Cc: Andy Lutomirski 
Cc: Oleg Nesterov 
Cc: 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Sasha Levin

KVM: VMX: avoid guest hang on invalid invept instruction

2016-04-18T12:49:37+00:00

[ Upstream commit 2849eb4f99d54925c543db12917127f88b3c38ff ]

A guest executing an invalid invept instruction would hang
because the instruction pointer was not updated.

Cc: stable@vger.kernel.org
Fixes: bfd0a56b90005f8c8a004baf407ad90045c2b11e
Reviewed-by: David Matlack 
Signed-off-by: Paolo Bonzini 
Signed-off-by: Sasha Levin

x86/apic: Fix suspicious RCU usage in smp_trace_call_function_interrupt()

2016-04-18T12:49:35+00:00

[ Upstream commit 7834c10313fb823e538f2772be78edcdeed2e6e3 ]

Since 4.4, I've been able to trigger this occasionally:

===============================
[ INFO: suspicious RCU usage. ]
4.5.0-rc7-think+ #3 Not tainted
Cc: Andi Kleen 
Link: http://lkml.kernel.org/r/20160315012054.GA17765@codemonkey.org.uk
Signed-off-by: Thomas Gleixner 

-------------------------------
./arch/x86/include/asm/msr-trace.h:47 suspicious rcu_dereference_check() usage!

other info that might help us debug this:

RCU used illegally from idle CPU!
rcu_scheduler_active = 1, debug_locks = 1
RCU used illegally from extended quiescent state!
no locks held by swapper/3/0.

stack backtrace:
CPU: 3 PID: 0 Comm: swapper/3 Not tainted 4.5.0-rc7-think+ #3
 ffffffff92f821e0 1f3e5c340597d7fc ffff880468e07f10 ffffffff92560c2a
 ffff880462145280 0000000000000001 ffff880468e07f40 ffffffff921376a6
 ffffffff93665ea0 0000cc7c876d28da 0000000000000005 ffffffff9383dd60
Call Trace:
   [] dump_stack+0x67/0x9d
 [] lockdep_rcu_suspicious+0xe6/0x100
 [] do_trace_write_msr+0x127/0x1a0
 [] native_apic_msr_eoi_write+0x23/0x30
 [] smp_trace_call_function_interrupt+0x38/0x360
 [] trace_call_function_interrupt+0x90/0xa0
   [] ? cpuidle_enter_state+0x1b4/0x520

Move the entering_irq() call before ack_APIC_irq(), because entering_irq()
tells the RCU susbstems to end the extended quiescent state, so that the
following trace call in ack_APIC_irq() works correctly.

Suggested-by: Andi Kleen 
Fixes: 4787c368a9bc "x86/tracing: Add irq_enter/exit() in smp_trace_reschedule_interrupt()"
Signed-off-by: Dave Jones 
Signed-off-by: Thomas Gleixner 
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin

x86/iopl: Fix iopl capability check on Xen PV

2016-04-18T12:49:33+00:00

[ Upstream commit c29016cf41fe9fa994a5ecca607cf5f1cd98801e ]

iopl(3) is supposed to work if iopl is already 3, even if
unprivileged.  This didn't work right on Xen PV.  Fix it.

Reviewewd-by: Jan Beulich 
Signed-off-by: Andy Lutomirski 
Cc: Andrew Cooper 
Cc: Andy Lutomirski 
Cc: Boris Ostrovsky 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: David Vrabel 
Cc: Denys Vlasenko 
Cc: H. Peter Anvin 
Cc: Jan Beulich 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: stable@vger.kernel.org
Link: http://lkml.kernel.org/r/8ce12013e6e4c0a44a97e316be4a6faff31bd5ea.1458162709.git.luto@kernel.org
Signed-off-by: Ingo Molnar 
Signed-off-by: Sasha Levin

ARM: dts: sunxi: Adjust touchscreen compatible for sun5i and later

2016-04-18T12:49:33+00:00

[ Upstream commit 8bf1b9b3d90194a174493febc731f7783f2adf1a ]

The touchscreen controller in the A13 and later has a different temperature
curve than the one in the original A10, change the compatible for the A13 and
later so that the kernel will use the correct curve.

Reported-by: Tong Zhang 
Signed-off-by: Hans de Goede 
Signed-off-by: Maxime Ripard 
Signed-off-by: Sasha Levin

s390/pci: enforce fmb page boundary rule

2016-04-18T12:49:30+00:00

[ Upstream commit 80c544ded25ac14d7cc3e555abb8ed2c2da99b84 ]

The function measurement block must not cross a page boundary. Ensure
that by raising the alignment requirement to the smallest power of 2
larger than the size of the fmb.

Fixes: d0b088531 ("s390/pci: performance statistics and debug infrastructure")
Cc: stable@vger.kernel.org # v3.8+
Signed-off-by: Sebastian Ott 
Signed-off-by: Martin Schwidefsky 
Signed-off-by: Sasha Levin

s390/pci: extract software counters from fmb

2016-04-18T12:49:30+00:00

[ Upstream commit 6001018ae8c659e624351d2e73b1272bacd68d6a ]

The software counters are not a part of the function measurement
block. Also we do not check for zdev->fmb != NULL when using these
counters (function measurement can be toggled at runtime). Just move
the software counters to struct zpci_dev.

Signed-off-by: Sebastian Ott 
Signed-off-by: Martin Schwidefsky 
Signed-off-by: Sasha Levin

xtensa: clear all DBREAKC registers on start

2016-04-18T12:49:28+00:00

[ Upstream commit 7de7ac785ae18a2cdc78d7560f48e3213d9ea0ab ]

There are XCHAL_NUM_DBREAK registers, clear them all.
This also fixes cryptic assembler error message with binutils 2.25 when
XCHAL_NUM_DBREAK is 0:

  as: out of memory allocating 18446744073709551575 bytes after a total
  of 495616 bytes

Cc: stable@vger.kernel.org
Signed-off-by: Max Filippov 
Signed-off-by: Sasha Levin

xtensa: fix preemption in {clear,copy}_user_highpage

2016-04-18T12:49:28+00:00

[ Upstream commit a67cc9aa2dfc6e66addf240bbd79e16e01565e81 ]

Disabling pagefault makes little sense there, preemption disabling is
what was meant.

Cc: stable@vger.kernel.org
Signed-off-by: Max Filippov 
Signed-off-by: Sasha Levin