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

x86/mm, mm/hwpoison: Clear PRESENT bit for kernel 1:1 mappings of poison pages

2017-09-20T06:27:48+00:00

commit ce0fa3e56ad20f04d8252353dcd24e924abdafca upstream.

Speculative processor accesses may reference any memory that has a
valid page table entry.  While a speculative access won't generate
a machine check, it will log the error in a machine check bank. That
could cause escalation of a subsequent error since the overflow bit
will be then set in the machine check bank status register.

Code has to be double-plus-tricky to avoid mentioning the 1:1 virtual
address of the page we want to map out otherwise we may trigger the
very problem we are trying to avoid.  We use a non-canonical address
that passes through the usual Linux table walking code to get to the
same "pte".

Thanks to Dave Hansen for reviewing several iterations of this.

Also see:

  http://marc.info/?l=linux-mm&m=149860136413338&w=2

Signed-off-by: Tony Luck 
Cc: Andrew Morton 
Cc: Andy Lutomirski 
Cc: Borislav Petkov 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: Dave Hansen 
Cc: Denys Vlasenko 
Cc: Elliott, Robert (Persistent Memory) 
Cc: H. Peter Anvin 
Cc: Josh Poimboeuf 
Cc: Linus Torvalds 
Cc: Naoya Horiguchi 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: linux-mm@kvack.org
Link: http://lkml.kernel.org/r/20170816171803.28342-1-tony.luck@intel.com
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

x86/switch_to/64: Rewrite FS/GS switching yet again to fix AMD CPUs

2017-09-20T06:27:48+00:00

commit e137a4d8f4dd2e277e355495b6b2cb241a8693c3 upstream.

Switching FS and GS is a mess, and the current code is still subtly
wrong: it assumes that "Loading a nonzero value into FS sets the
index and base", which is false on AMD CPUs if the value being
loaded is 1, 2, or 3.

(The current code came from commit 3e2b68d752c9 ("x86/asm,
sched/x86: Rewrite the FS and GS context switch code"), which made
it better but didn't fully fix it.)

Rewrite it to be much simpler and more obviously correct.  This
should fix it fully on AMD CPUs and shouldn't adversely affect
performance.

Signed-off-by: Andy Lutomirski 
Cc: Borislav Petkov 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: Chang Seok 
Cc: Denys Vlasenko 
Cc: H. Peter Anvin 
Cc: Josh Poimboeuf 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

x86/fsgsbase/64: Report FSBASE and GSBASE correctly in core dumps

2017-09-20T06:27:48+00:00

commit 9584d98bed7a7a904d0702ad06bbcc94703cb5b4 upstream.

In ELF_COPY_CORE_REGS, we're copying from the current task, so
accessing thread.fsbase and thread.gsbase makes no sense.  Just read
the values from the CPU registers.

In practice, the old code would have been correct most of the time
simply because thread.fsbase and thread.gsbase usually matched the
CPU registers.

Signed-off-by: Andy Lutomirski 
Cc: Borislav Petkov 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: Chang Seok 
Cc: Denys Vlasenko 
Cc: H. Peter Anvin 
Cc: Josh Poimboeuf 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

x86/fsgsbase/64: Fully initialize FS and GS state in start_thread_common

2017-09-20T06:27:48+00:00

commit 767d035d838f4fd6b5a5bbd7a3f6d293b7f65a49 upstream.

execve used to leak FSBASE and GSBASE on AMD CPUs.  Fix it.

The security impact of this bug is small but not quite zero -- it
could weaken ASLR when a privileged task execs a less privileged
program, but only if program changed bitness across the exec, or the
child binary was highly unusual or actively malicious.  A child
program that was compromised after the exec would not have access to
the leaked base.

Signed-off-by: Andy Lutomirski 
Cc: Borislav Petkov 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: Chang Seok 
Cc: Denys Vlasenko 
Cc: H. Peter Anvin 
Cc: Josh Poimboeuf 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

ARM: 8692/1: mm: abort uaccess retries upon fatal signal

2017-09-13T21:20:54+00:00

commit 746a272e44141af24a02f6c9b0f65f4c4598ed42 upstream.

When there's a fatal signal pending, arm's do_page_fault()
implementation returns 0. The intent is that we'll return to the
faulting userspace instruction, delivering the signal on the way.

However, if we take a fatal signal during fixing up a uaccess, this
results in a return to the faulting kernel instruction, which will be
instantly retried, resulting in the same fault being taken forever. As
the task never reaches userspace, the signal is not delivered, and the
task is left unkillable. While the task is stuck in this state, it can
inhibit the forward progress of the system.

To avoid this, we must ensure that when a fatal signal is pending, we
apply any necessary fixup for a faulting kernel instruction. Thus we
will return to an error path, and it is up to that code to make forward
progress towards delivering the fatal signal.

Signed-off-by: Mark Rutland 
Reviewed-by: Steve Capper 
Signed-off-by: Russell King 
Signed-off-by: Greg Kroah-Hartman

ARM64: dts: marvell: armada-37xx: Fix GIC maintenance interrupt

2017-09-13T21:20:54+00:00

commit 95696d292e204073433ed2ef3ff4d3d8f42a8248 upstream.

The GIC-500 integrated in the Armada-37xx SoCs is compliant with
the GICv3 architecture, and thus provides a maintenance interrupt
that is required for hypervisors to function correctly.

With the interrupt provided in the DT, KVM now works as it should.
Tested on an Espressobin system.

Fixes: adbc3695d9e4 ("arm64: dts: add the Marvell Armada 3700 family and a development board")
Signed-off-by: Marc Zyngier 
Signed-off-by: Gregory CLEMENT 
Signed-off-by: Greg Kroah-Hartman

KVM: SVM: Limit PFERR_NESTED_GUEST_PAGE error_code check to L1 guest

2017-09-13T21:20:53+00:00

commit 64531a3b70b17c8d3e77f2e49e5e1bb70f571266 upstream.

Commit 147277540bbc ("kvm: svm: Add support for additional SVM NPF error
codes", 2016-11-23) added a new error code to aid nested page fault
handling.  The commit unprotects (kvm_mmu_unprotect_page) the page when
we get a NPF due to guest page table walk where the page was marked RO.

However, if an L0->L2 shadow nested page table can also be marked read-only
when a page is read only in L1's nested page table.  If such a page
is accessed by L2 while walking page tables it can cause a nested
page fault (page table walks are write accesses).  However, after
kvm_mmu_unprotect_page we may get another page fault, and again in an
endless stream.

To cover this use case, we qualify the new error_code check with
vcpu->arch.mmu_direct_map so that the error_code check would run on L1
guest, and not the L2 guest.  This avoids hitting the above scenario.

Fixes: 147277540bbc54119172481c8ef6d930cc9fbfc2
Cc: Paolo Bonzini 
Cc: Radim Krčmář 
Cc: Thomas Lendacky 
Signed-off-by: Brijesh Singh 
Signed-off-by: Paolo Bonzini 
Signed-off-by: Greg Kroah-Hartman

s390/mm: avoid empty zero pages for KVM guests to avoid postcopy hangs

2017-09-09T15:39:26+00:00

commit fa41ba0d08de7c975c3e94d0067553f9b934221f upstream.

Right now there is a potential hang situation for postcopy migrations,
if the guest is enabling storage keys on the target system during the
postcopy process.

For storage key virtualization, we have to forbid the empty zero page as
the storage key is a property of the physical page frame.  As we enable
storage key handling lazily we then drop all mappings for empty zero
pages for lazy refaulting later on.

This does not work with the postcopy migration, which relies on the
empty zero page never triggering a fault again in the future. The reason
is that postcopy migration will simply read a page on the target system
if that page is a known zero page to fault in an empty zero page.  At
the same time postcopy remembers that this page was already transferred
- so any future userfault on that page will NOT be retransmitted again
to avoid races.

If now the guest enters the storage key mode while in postcopy, we will
break this assumption of postcopy.

The solution is to disable the empty zero page for KVM guests early on
and not during storage key enablement. With this change, the postcopy
migration process is guaranteed to start after no zero pages are left.

As guest pages are very likely not empty zero pages anyway the memory
overhead is also pretty small.

While at it this also adds proper page table locking to the zero page
removal.

Signed-off-by: Christian Borntraeger 
Acked-by: Janosch Frank 
Signed-off-by: Martin Schwidefsky 
Signed-off-by: Greg Kroah-Hartman

Merge branch 'upstream' of git://git.linux-mips.org/pub/scm/ralf/upstream-linus

2017-09-03T16:50:26+00:00

Pull MIPS fixes from Ralf Baechle:
 "The two indirect syscall fixes have sat in linux-next for a few days.
  I did check back with a hardware designer to ensure a SYNC is really
  what's required for the GIC fix and so the GIC fix didn't make it into
  to linux-next in time for this final pull request.

  It builds in local build tests and passes Imagination's test system"

* 'upstream' of git://git.linux-mips.org/pub/scm/ralf/upstream-linus:
  irqchip: mips-gic: SYNC after enabling GIC region
  MIPS: Remove pt_regs adjustments in indirect syscall handler
  MIPS: seccomp: Fix indirect syscall args

Merge branch 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

2017-09-03T16:35:21+00:00

Pull x86 fixes from Thomas Gleixner:

 - Expand the space for uncompressing as the LZ4 worst case does not fit
   into the currently reserved space

 - Validate boot parameters more strictly to prevent out of bound access
   in the decompressor/boot code

 - Fix off by one errors in get_segment_base()

* 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  x86/boot: Prevent faulty bootparams.screeninfo from causing harm
  x86/boot: Provide more slack space during decompression
  x86/ldt: Fix off by one in get_segment_base()