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

kvm: x86: do not leak guest xcr0 into host interrupt handlers

2016-04-20T13:41:00+00:00

[ Upstream commit fc5b7f3bf1e1414bd4e91db6918c85ace0c873a5 ]

An interrupt handler that uses the fpu can kill a KVM VM, if it runs
under the following conditions:
 - the guest's xcr0 register is loaded on the cpu
 - the guest's fpu context is not loaded
 - the host is using eagerfpu

Note that the guest's xcr0 register and fpu context are not loaded as
part of the atomic world switch into "guest mode". They are loaded by
KVM while the cpu is still in "host mode".

Usage of the fpu in interrupt context is gated by irq_fpu_usable(). The
interrupt handler will look something like this:

if (irq_fpu_usable()) {
        kernel_fpu_begin();

        [... code that uses the fpu ...]

        kernel_fpu_end();
}

As long as the guest's fpu is not loaded and the host is using eager
fpu, irq_fpu_usable() returns true (interrupted_kernel_fpu_idle()
returns true). The interrupt handler proceeds to use the fpu with
the guest's xcr0 live.

kernel_fpu_begin() saves the current fpu context. If this uses
XSAVE[OPT], it may leave the xsave area in an undesirable state.
According to the SDM, during XSAVE bit i of XSTATE_BV is not modified
if bit i is 0 in xcr0. So it's possible that XSTATE_BV[i] == 1 and
xcr0[i] == 0 following an XSAVE.

kernel_fpu_end() restores the fpu context. Now if any bit i in
XSTATE_BV == 1 while xcr0[i] == 0, XRSTOR generates a #GP. The
fault is trapped and SIGSEGV is delivered to the current process.

Only pre-4.2 kernels appear to be vulnerable to this sequence of
events. Commit 653f52c ("kvm,x86: load guest FPU context more eagerly")
from 4.2 forces the guest's fpu to always be loaded on eagerfpu hosts.

This patch fixes the bug by keeping the host's xcr0 loaded outside
of the interrupts-disabled region where KVM switches into guest mode.

Cc: stable@vger.kernel.org
Suggested-by: Andy Lutomirski 
Signed-off-by: David Matlack 
[Move load after goto cancel_injection. - Paolo]
Signed-off-by: Paolo Bonzini 

Signed-off-by: Sasha Levin

parisc: Unbreak handling exceptions from kernel modules

2016-04-20T13:40:59+00:00

[ Upstream commit 2ef4dfd9d9f288943e249b78365a69e3ea3ec072 ]

Handling exceptions from modules never worked on parisc.
It was just masked by the fact that exceptions from modules
don't happen during normal use.

When a module triggers an exception in get_user() we need to load the
main kernel dp value before accessing the exception_data structure, and
afterwards restore the original dp value of the module on exit.

Noticed-by: Mikulas Patocka 
Signed-off-by: Helge Deller 
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin

parisc: percpu: update comments referring to __get_cpu_var

2016-04-20T13:40:59+00:00

[ Upstream commit 6ddb798f0248e3460c2dce76af5cb30a980efccd ]

__get_cpu_var was removed. Update comments to refer to
this_cpu_ptr() instead.

Signed-off-by: Christoph Lameter 
Cc: "James E.J. Bottomley" 
Cc: Tejun Heo 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Sasha Levin

parisc: Fix kernel crash with reversed copy_from_user()

2016-04-20T13:40:58+00:00

[ Upstream commit ef72f3110d8b19f4c098a0bff7ed7d11945e70c6 ]

The kernel module testcase (lib/test_user_copy.c) exhibited a kernel
crash on parisc if the parameters for copy_from_user were reversed
("illegal reversed copy_to_user" testcase).

Fix this potential crash by checking the fault handler if the faulting
address is in the exception table.

Signed-off-by: Helge Deller 
Cc: stable@vger.kernel.org
Cc: Kees Cook 
Signed-off-by: Sasha Levin

parisc: Avoid function pointers for kernel exception routines

2016-04-20T13:40:58+00:00

[ Upstream commit e3893027a300927049efc1572f852201eb785142 ]

We want to avoid the kernel module loader to create function pointers
for the kernel fixup routines of get_user() and put_user(). Changing
the external reference from function type to int type fixes this.

This unbreaks exception handling for get_user() and put_user() when
called from a kernel module.

Signed-off-by: Helge Deller 
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin

KVM: x86: Inject pending interrupt even if pending nmi exist

2016-04-20T05:27:43+00:00

[ Upstream commit 321c5658c5e9192dea0d58ab67cf1791e45b2b26 ]

Non maskable interrupts (NMI) are preferred to interrupts in current
implementation. If a NMI is pending and NMI is blocked by the result
of nmi_allowed(), pending interrupt is not injected and
enable_irq_window() is not executed, even if interrupts injection is
allowed.

In old kernel (e.g. 2.6.32), schedule() is often called in NMI context.
In this case, interrupts are needed to execute iret that intends end
of NMI. The flag of blocking new NMI is not cleared until the guest
execute the iret, and interrupts are blocked by pending NMI. Due to
this, iret can't be invoked in the guest, and the guest is starved
until block is cleared by some events (e.g. canceling injection).

This patch injects pending interrupts, when it's allowed, even if NMI
is blocked. And, If an interrupts is pending after executing
inject_pending_event(), enable_irq_window() is executed regardless of
NMI pending counter.

Cc: stable@vger.kernel.org
Signed-off-by: Yuki Shibuya 
Suggested-by: Paolo Bonzini 
Signed-off-by: Paolo Bonzini 
Signed-off-by: Sasha Levin

ARM: OMAP2+: hwmod: Fix updating of sysconfig register

2016-04-20T05:19:56+00:00

[ Upstream commit 3ca4a238106dedc285193ee47f494a6584b6fd2f ]

Commit 127500ccb766f ("ARM: OMAP2+: Only write the sysconfig on idle
when necessary") talks about verification of sysconfig cache value before
updating it, only during idle path. But the patch is adding the
verification in the enable path. So, adding the check in a proper place
as per the commit description.

Not keeping this check during enable path as there is a chance of losing
context and it is safe to do on idle as the context of the register will
never be lost while the device is active.

Signed-off-by: Lokesh Vutla 
Acked-by: Tero Kristo 
Cc: Jon Hunter 
Cc:  # 3.12+
Fixes: commit 127500ccb766 "ARM: OMAP2+: Only write the sysconfig on idle when necessary"
[paul@pwsan.com: appears to have been caused by my own mismerge of the
 originally posted patch]
Signed-off-by: Paul Walmsley 

Signed-off-by: Sasha Levin

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