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

MIPS: fix Select HAVE_IRQ_EXIT_ON_IRQ_STACK patch.

2017-04-21T07:30:08+00:00

Commit f017e58da4aba293e4a6ab62ca5d4801f79cc929 which was commit
3cc3434fd6307d06b53b98ce83e76bf9807689b9 upstream, was misapplied to the
4.4 stable kernel.

This patch fixes this and moves the chunk to the proper Kconfig area.

Reported-by: "Maciej W. Rozycki" 
Cc: Matt Redfearn 
Cc: Jason A. Donenfeld 
Cc: Thomas Gleixner 
Cc: Ralf Baechle 
Cc: Amit Pundir 
Signed-off-by: Greg Kroah-Hartman

mm: Tighten x86 /dev/mem with zeroing reads

2017-04-21T07:30:07+00:00

commit a4866aa812518ed1a37d8ea0c881dc946409de94 upstream.

Under CONFIG_STRICT_DEVMEM, reading System RAM through /dev/mem is
disallowed. However, on x86, the first 1MB was always allowed for BIOS
and similar things, regardless of it actually being System RAM. It was
possible for heap to end up getting allocated in low 1MB RAM, and then
read by things like x86info or dd, which would trip hardened usercopy:

usercopy: kernel memory exposure attempt detected from ffff880000090000 (dma-kmalloc-256) (4096 bytes)

This changes the x86 exception for the low 1MB by reading back zeros for
System RAM areas instead of blindly allowing them. More work is needed to
extend this to mmap, but currently mmap doesn't go through usercopy, so
hardened usercopy won't Oops the kernel.

Reported-by: Tommi Rantala 
Tested-by: Tommi Rantala 
Signed-off-by: Kees Cook 
Cc: Brad Spengler 
Signed-off-by: Greg Kroah-Hartman

powerpc: Disable HFSCR[TM] if TM is not supported

2017-04-21T07:30:06+00:00

commit 7ed23e1bae8bf7e37fd555066550a00b95a3a98b upstream.

On Power8 & Power9 the early CPU inititialisation in __init_HFSCR()
turns on HFSCR[TM] (Hypervisor Facility Status and Control Register
[Transactional Memory]), but that doesn't take into account that TM
might be disabled by CPU features, or disabled by the kernel being built
with CONFIG_PPC_TRANSACTIONAL_MEM=n.

So later in boot, when we have setup the CPU features, clear HSCR[TM] if
the TM CPU feature has been disabled. We use CPU_FTR_TM_COMP to account
for the CONFIG_PPC_TRANSACTIONAL_MEM=n case.

Without this a KVM guest might try use TM, even if told not to, and
cause an oops in the host kernel. Typically the oops is seen in
__kvmppc_vcore_entry() and may or may not be fatal to the host, but is
always bad news.

In practice all shipping CPU revisions do support TM, and all host
kernels we are aware of build with TM support enabled, so no one should
actually be able to hit this in the wild.

Fixes: 2a3563b023e5 ("powerpc: Setup in HFSCR for POWER8")
Cc: stable@vger.kernel.org # v3.10+
Signed-off-by: Benjamin Herrenschmidt 
Tested-by: Sam Bobroff 
[mpe: Rewrite change log with input from Sam, add Fixes/stable]
Signed-off-by: Michael Ellerman 
[sb: Backported to linux-4.4.y: adjusted context]
Signed-off-by: Sam Bobroff 
Signed-off-by: Greg Kroah-Hartman

kvm: fix page struct leak in handle_vmon

2017-04-21T07:30:06+00:00

commit 06ce521af9558814b8606c0476c54497cf83a653 upstream.

handle_vmon gets a reference on VMXON region page,
but does not release it. Release the reference.

Found by syzkaller; based on a patch by Dmitry.

Reported-by: Dmitry Vyukov 
Signed-off-by: Paolo Bonzini 
[bwh: Backported to 3.16: use skip_emulated_instruction()]
Signed-off-by: Ben Hutchings 
Signed-off-by: Greg Kroah-Hartman

Revert "MIPS: Lantiq: Fix cascaded IRQ setup"

2017-04-21T07:30:06+00:00

This reverts commit 6280ac931a23d3fa40cd26057576abcf90a4f22d which is
commit 6c356eda225e3ee134ed4176b9ae3a76f793f4dd upstream.

It shouldn't have been included in a stable release.

Reported-by: Amit Pundir 
Cc: Felix Fietkau 
Cc: John Crispin 
Cc: James Hogan 
Signed-off-by: Greg Kroah-Hartman

x86/vdso: Plug race between mapping and ELF header setup

2017-04-21T07:30:05+00:00

commit 6fdc6dd90272ce7e75d744f71535cfbd8d77da81 upstream.

The vsyscall32 sysctl can racy against a concurrent fork when it switches
from disabled to enabled:

    arch_setup_additional_pages()
	if (vdso32_enabled)
           --> No mapping
                                        sysctl.vsysscall32()
                                          --> vdso32_enabled = true
    create_elf_tables()
      ARCH_DLINFO_IA32
        if (vdso32_enabled) {
           --> Add VDSO entry with NULL pointer

Make ARCH_DLINFO_IA32 check whether the VDSO mapping has been set up for
the newly forked process or not.

Signed-off-by: Thomas Gleixner 
Acked-by: Andy Lutomirski 
Cc: Peter Zijlstra 
Cc: Mathias Krause 
Link: http://lkml.kernel.org/r/20170410151723.602367196@linutronix.de
Signed-off-by: Thomas Gleixner 
Signed-off-by: Greg Kroah-Hartman

x86/vdso: Ensure vdso32_enabled gets set to valid values only

2017-04-21T07:30:05+00:00

commit c06989da39cdb10604d572c8c7ea8c8c97f3c483 upstream.

vdso_enabled can be set to arbitrary integer values via the kernel command
line 'vdso32=' parameter or via 'sysctl abi.vsyscall32'.

load_vdso32() only maps VDSO if vdso_enabled == 1, but ARCH_DLINFO_IA32
merily checks for vdso_enabled != 0. As a consequence the AT_SYSINFO_EHDR
auxiliary vector for the VDSO_ENTRY is emitted with a NULL pointer which
causes a segfault when the application tries to use the VDSO.

Restrict the valid arguments on the command line and the sysctl to 0 and 1.

Fixes: b0b49f2673f0 ("x86, vdso: Remove compat vdso support")
Signed-off-by: Mathias Krause 
Acked-by: Andy Lutomirski 
Cc: Peter Zijlstra 
Cc: Roland McGrath 
Link: http://lkml.kernel.org/r/1491424561-7187-1-git-send-email-minipli@googlemail.com
Link: http://lkml.kernel.org/r/20170410151723.518412863@linutronix.de
Signed-off-by: Thomas Gleixner 
Signed-off-by: Greg Kroah-Hartman

perf/x86: Avoid exposing wrong/stale data in intel_pmu_lbr_read_32()

2017-04-21T07:30:05+00:00

commit f2200ac311302fcdca6556fd0c5127eab6c65a3e upstream.

When the perf_branch_entry::{in_tx,abort,cycles} fields were added,
intel_pmu_lbr_read_32() wasn't updated to initialize them.

Signed-off-by: Peter Zijlstra (Intel) 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: linux-kernel@vger.kernel.org
Fixes: 135c5612c460 ("perf/x86/intel: Support Haswell/v4 LBR format")
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

MIPS: IRQ Stack: Fix erroneous jal to plat_irq_dispatch

2017-04-18T05:14:36+00:00

commit c25f8064c1d5731a2ce5664def890140dcdd3e5c upstream.

Commit dda45f701c9d ("MIPS: Switch to the irq_stack in interrupts")
changed both the normal and vectored interrupt handlers. Unfortunately
the vectored version, "except_vec_vi_handler", was incorrectly modified
to unconditionally jal to plat_irq_dispatch, rather than doing a jalr to
the vectored handler that has been set up. This is ok for many platforms
which set the vectored handler to plat_irq_dispatch anyway, but will
cause problems with platforms that use other handlers.

Fixes: dda45f701c9d ("MIPS: Switch to the irq_stack in interrupts")
Signed-off-by: Matt Redfearn 
Cc: Ralf Baechle 
Cc: Paul Burton 
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/15110/
Signed-off-by: James Hogan 
Signed-off-by: Amit Pundir 
Signed-off-by: Greg Kroah-Hartman

MIPS: Select HAVE_IRQ_EXIT_ON_IRQ_STACK

2017-04-18T05:14:36+00:00

commit 3cc3434fd6307d06b53b98ce83e76bf9807689b9 upstream.

Since do_IRQ is now invoked on a separate IRQ stack, we select
HAVE_IRQ_EXIT_ON_IRQ_STACK so that softirq's may be invoked directly
from irq_exit(), rather than requiring do_softirq_own_stack.

Signed-off-by: Matt Redfearn 
Acked-by: Jason A. Donenfeld 
Cc: Thomas Gleixner 
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/14744/
Signed-off-by: Ralf Baechle 
Signed-off-by: Amit Pundir 
Signed-off-by: Greg Kroah-Hartman