linux.git/arch, branch v4.13.7

kvm/x86: Avoid async PF preempting the kernel incorrectly

2017-10-12T09:56:18+00:00

commit a2b7861bb33b2538420bb5d8554153484d3f961f upstream.

Currently, in PREEMPT_COUNT=n kernel, kvm_async_pf_task_wait() could call
schedule() to reschedule in some cases.  This could result in
accidentally ending the current RCU read-side critical section early,
causing random memory corruption in the guest, or otherwise preempting
the currently running task inside between preempt_disable and
preempt_enable.

The difficulty to handle this well is because we don't know whether an
async PF delivered in a preemptible section or RCU read-side critical section
for PREEMPT_COUNT=n, since preempt_disable()/enable() and rcu_read_lock/unlock()
are both no-ops in that case.

To cure this, we treat any async PF interrupting a kernel context as one
that cannot be preempted, preventing kvm_async_pf_task_wait() from choosing
the schedule() path in that case.

To do so, a second parameter for kvm_async_pf_task_wait() is introduced,
so that we know whether it's called from a context interrupting the
kernel, and the parameter is set properly in all the callsites.

Cc: "Paul E. McKenney" 
Cc: Peter Zijlstra 
Cc: Wanpeng Li 
Signed-off-by: Boqun Feng 
Signed-off-by: Radim Krčmář 
Signed-off-by: Greg Kroah-Hartman

KVM: PPC: Book3S: Fix server always zero from kvmppc_xive_get_xive()

2017-10-12T09:56:18+00:00

commit 2fb1e946450a4fef74bb72f360555f7760d816f0 upstream.

In KVM's XICS-on-XIVE emulation, kvmppc_xive_get_xive() returns the
value of state->guest_server as "server". However, this value is not
set by it's counterpart kvmppc_xive_set_xive(). When the guest uses
this interface to migrate interrupts away from a CPU that is going
offline, it sees all interrupts as belonging to CPU 0, so they are
left assigned to (now) offline CPUs.

This patch removes the guest_server field from the state, and returns
act_server in it's place (that is, the CPU actually handling the
interrupt, which may differ from the one requested).

Fixes: 5af50993850a ("KVM: PPC: Book3S HV: Native usage of the XIVE interrupt controller")
Signed-off-by: Sam Bobroff 
Acked-by: Benjamin Herrenschmidt 
Signed-off-by: Radim Krčmář 
Signed-off-by: Greg Kroah-Hartman

arm64: Ensure the instruction emulation is ready for userspace

2017-10-12T09:56:16+00:00

commit c0d8832e78cbfd4a64b7112e34920af4b0b0e60e upstream.

We trap and emulate some instructions (e.g, mrs, deprecated instructions)
for the userspace. However the handlers for these are registered as
late_initcalls and the userspace could be up and running from the initramfs
by that time (with populate_rootfs, which is a rootfs_initcall()). This
could cause problems for the early applications ending up in failure
like :

[   11.152061] modprobe[93]: undefined instruction: pc=0000ffff8ca48ff4

This patch promotes the specific calls to core_initcalls, which are
guaranteed to be completed before we hit userspace.

Cc: Dave Martin 
Cc: Matthias Brugger 
Cc: James Morse 
Reported-by: Matwey V. Kornilov 
Signed-off-by: Suzuki K Poulose 
Signed-off-by: Catalin Marinas 
Signed-off-by: Greg Kroah-Hartman

arm64: dt marvell: Fix AP806 system controller size

2017-10-12T09:56:16+00:00

commit 9e7460fc325dad06d2066abdbc1f4dd49456f9a4 upstream.

Extend the container size to 0x2000 to include the gpio controller at
offset 0x1040.

While at it, add start address notation to the gpio node name to match
its 'offset' property.

Fixes: 63dac0f4924b ("arm64: dts: marvell: add gpio support for Armada
7K/8K")
Signed-off-by: Baruch Siach 
Signed-off-by: Gregory CLEMENT 
Signed-off-by: Greg Kroah-Hartman

powerpc/tm: Fix illegal TM state in signal handler

2017-10-12T09:56:14+00:00

commit 044215d145a7a8a60ffa8fdc859d110a795fa6ea upstream.

Currently it's possible that on returning from the signal handler
through the restore_tm_sigcontexts() code path (e.g. from a signal
caught due to a `trap` instruction executed in the middle of an HTM
block, or a deliberately constructed sigframe) an illegal TM state
(like TS=10 TM=0, i.e. "T0") is set in SRR1 and when `rfid` sets
implicitly the MSR register from SRR1 register on return to userspace
it causes a TM Bad Thing exception.

That illegal state can be set (a) by a malicious user that disables
the TM bit by tweaking the bits in uc_mcontext before returning from
the signal handler or (b) by a sufficient number of context switches
occurring such that the load_tm counter overflows and TM is disabled
whilst in the signal handler.

This commit fixes the illegal TM state by ensuring that TM bit is
always enabled before we return from restore_tm_sigcontexts(). A small
comment correction is made as well.

Fixes: 5d176f751ee3 ("powerpc: tm: Enable transactional memory (TM) lazily for userspace")
Signed-off-by: Gustavo Romero 
Signed-off-by: Breno Leitao 
Signed-off-by: Cyril Bur 
Signed-off-by: Michael Ellerman 
Signed-off-by: Greg Kroah-Hartman

powerpc/64s: Use emergency stack for kernel TM Bad Thing program checks

2017-10-12T09:56:14+00:00

commit 265e60a170d0a0ecfc2d20490134ed2c48dd45ab upstream.

When using transactional memory (TM), the CPU can be in one of six
states as far as TM is concerned, encoded in the Machine State
Register (MSR). Certain state transitions are illegal and if attempted
trigger a "TM Bad Thing" type program check exception.

If we ever hit one of these exceptions it's treated as a bug, ie. we
oops, and kill the process and/or panic, depending on configuration.

One case where we can trigger a TM Bad Thing, is when returning to
userspace after a system call or interrupt, using RFID. When this
happens the CPU first restores the user register state, in particular
r1 (the stack pointer) and then attempts to update the MSR. However
the MSR update is not allowed and so we take the program check with
the user register state, but the kernel MSR.

This tricks the exception entry code into thinking we have a bad
kernel stack pointer, because the MSR says we're coming from the
kernel, but r1 is pointing to userspace.

To avoid this we instead always switch to the emergency stack if we
take a TM Bad Thing from the kernel. That way none of the user
register values are used, other than for printing in the oops message.

This is the fix for CVE-2017-1000255.

Fixes: 5d176f751ee3 ("powerpc: tm: Enable transactional memory (TM) lazily for userspace")
Signed-off-by: Cyril Bur 
[mpe: Rewrite change log & comments, tweak asm slightly]
Signed-off-by: Michael Ellerman 
Signed-off-by: Greg Kroah-Hartman

powerpc: Fix action argument for cpufeatures-based TLB flush

2017-10-12T09:56:14+00:00

commit 3b7af5c0fd9631762d1c4d7b4cee76f571dd3c2c upstream.

Commit 41d0c2ecde19 ("powerpc/powernv: Fix local TLB flush for boot
and MCE on POWER9") introduced calls to __flush_tlb_power[89] from the
cpufeatures code, specifying the number of sets to flush.

However, these functions take an action argument, not a number of
sets. This means we hit the BUG() in __flush_tlb_{206,300} when using
cpufeatures-style configuration.

This change passes TLB_INVAL_SCOPE_GLOBAL instead.

Fixes: 41d0c2ecde19 ("powerpc/powernv: Fix local TLB flush for boot and MCE on POWER9")
Signed-off-by: Jeremy Kerr 
Reviewed-by: Nicholas Piggin 
Signed-off-by: Michael Ellerman 
Signed-off-by: Greg Kroah-Hartman

powerpc/powernv: Increase memory block size to 1GB on radix

2017-10-12T09:56:14+00:00

commit 53ecde0b9126ff140abe3aefd7f0ec64d6fa36b0 upstream.

Memory hot unplug on PowerNV radix hosts is broken. Our memory block
size is 256MB but since we map the linear region with very large
pages, each pte we tear down maps 1GB.

A hot unplug of one 256MB memory block results in 768MB of memory
getting unintentionally unmapped. At this point we are likely to oops.

Fix this by increasing our memory block size to 1GB on PowerNV radix
hosts.

Fixes: 4b5d62ca17a1 ("powerpc/mm: add radix__remove_section_mapping()")
Signed-off-by: Anton Blanchard 
Signed-off-by: Michael Ellerman 
Signed-off-by: Greg Kroah-Hartman

bpf: fix bpf_tail_call() x64 JIT

2017-10-12T09:56:07+00:00

[ Upstream commit 90caccdd8cc0215705f18b92771b449b01e2474a ]

- bpf prog_array just like all other types of bpf array accepts 32-bit index.
  Clarify that in the comment.
- fix x64 JIT of bpf_tail_call which was incorrectly loading 8 instead of 4 bytes
- tighten corresponding check in the interpreter to stay consistent

The JIT bug can be triggered after introduction of BPF_F_NUMA_NODE flag
in commit 96eabe7a40aa in 4.14. Before that the map_flags would stay zero and
though JIT code is wrong it will check bounds correctly.
Hence two fixes tags. All other JITs don't have this problem.

Signed-off-by: Alexei Starovoitov 
Fixes: 96eabe7a40aa ("bpf: Allow selecting numa node during map creation")
Fixes: b52f00e6a715 ("x86: bpf_jit: implement bpf_tail_call() helper")
Acked-by: Daniel Borkmann 
Acked-by: Martin KaFai Lau 
Reviewed-by: Eric Dumazet 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

KVM: VMX: use cmpxchg64

2017-10-05T07:47:36+00:00

commit c0a1666bcb2a33e84187a15eabdcd54056be9a97 upstream.

This fixes a compilation failure on 32-bit systems.

Signed-off-by: Paolo Bonzini 
Signed-off-by: Greg Kroah-Hartman