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

kvm: arm/arm64: Force reading uncached stage2 PGD

2017-09-07T06:35:40+00:00

commit 2952a6070e07ebdd5896f1f5b861acad677caded upstream.

Make sure we don't use a cached value of the KVM stage2 PGD while
resetting the PGD.

Cc: Marc Zyngier 
Signed-off-by: Suzuki K Poulose 
Reviewed-by: Christoffer Dall 
Signed-off-by: Christoffer Dall 
Signed-off-by: Suzuki K Poulose 
Signed-off-by: Greg Kroah-Hartman

alpha: uapi: Add support for __SANE_USERSPACE_TYPES__

2017-09-07T06:35:40+00:00

commit cec80d82142ab25c71eee24b529cfeaf17c43062 upstream.

This fixes compiler errors in perf such as:

tests/attr.c: In function 'store_event':
tests/attr.c:66:27: error: format '%llu' expects argument of type 'long long unsigned int', but argument 6 has type '__u64 {aka long unsigned int}' [-Werror=format=]
  snprintf(path, PATH_MAX, "%s/event-%d-%llu-%d", dir,
                           ^

Signed-off-by: Ben Hutchings 
Tested-by: Michael Cree 
Signed-off-by: Matt Turner 
Signed-off-by: Greg Kroah-Hartman

arm64: fpsimd: Prevent registers leaking across exec

2017-09-02T05:07:54+00:00

commit 096622104e14d8a1db4860bd557717067a0515d2 upstream.

There are some tricky dependencies between the different stages of
flushing the FPSIMD register state during exec, and these can race
with context switch in ways that can cause the old task's regs to
leak across.  In particular, a context switch during the memset() can
cause some of the task's old FPSIMD registers to reappear.

Disabling preemption for this small window would be no big deal for
performance: preemption is already disabled for similar scenarios
like updating the FPSIMD registers in sigreturn.

So, instead of rearranging things in ways that might swap existing
subtle bugs for new ones, this patch just disables preemption
around the FPSIMD state flushing so that races of this type can't
occur here.  This brings fpsimd_flush_thread() into line with other
code paths.

Fixes: 674c242c9323 ("arm64: flush FP/SIMD state correctly after execve()")
Reviewed-by: Ard Biesheuvel 
Signed-off-by: Dave Martin 
Signed-off-by: Will Deacon 
Signed-off-by: Greg Kroah-Hartman

x86/io: Add "memory" clobber to insb/insw/insl/outsb/outsw/outsl

2017-09-02T05:07:53+00:00

commit 7206f9bf108eb9513d170c73f151367a1bdf3dbf upstream.

The x86 version of insb/insw/insl uses an inline assembly that does
not have the target buffer listed as an output. This can confuse
the compiler, leading it to think that a subsequent access of the
buffer is uninitialized:

  drivers/net/wireless/wl3501_cs.c: In function ‘wl3501_mgmt_scan_confirm’:
  drivers/net/wireless/wl3501_cs.c:665:9: error: ‘sig.status’ is used uninitialized in this function [-Werror=uninitialized]
  drivers/net/wireless/wl3501_cs.c:668:12: error: ‘sig.cap_info’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
  drivers/net/sb1000.c: In function 'sb1000_rx':
  drivers/net/sb1000.c:775:9: error: 'st[0]' is used uninitialized in this function [-Werror=uninitialized]
  drivers/net/sb1000.c:776:10: error: 'st[1]' may be used uninitialized in this function [-Werror=maybe-uninitialized]
  drivers/net/sb1000.c:784:11: error: 'st[1]' may be used uninitialized in this function [-Werror=maybe-uninitialized]

I tried to mark the exact input buffer as an output here, but couldn't
figure it out. As suggested by Linus, marking all memory as clobbered
however is good enough too. For the outs operations, I also add the
memory clobber, to force the input to be written to local variables.
This is probably already guaranteed by the "asm volatile", but it can't
hurt to do this for symmetry.

Suggested-by: Linus Torvalds 
Signed-off-by: Arnd Bergmann 
Acked-by: Linus Torvalds 
Cc: Borislav Petkov 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: Tom Lendacky 
Link: http://lkml.kernel.org/r/20170719125310.2487451-5-arnd@arndb.de
Link: https://lkml.org/lkml/2017/7/12/605
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

arm64: mm: abort uaccess retries upon fatal signal

2017-09-02T05:07:53+00:00

commit 289d07a2dc6c6b6f3e4b8a62669320d99dbe6c3d upstream.

When there's a fatal signal pending, arm64'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.

Cc: Catalin Marinas 
Cc: Laura Abbott 
Reviewed-by: Steve Capper 
Tested-by: Steve Capper 
Reviewed-by: James Morse 
Tested-by: James Morse 
Signed-off-by: Mark Rutland 
Signed-off-by: Will Deacon 
Signed-off-by: Greg Kroah-Hartman

kvm: arm/arm64: Fix race in resetting stage2 PGD

2017-09-02T05:07:53+00:00

commit 6c0d706b563af732adb094c5bf807437e8963e84 upstream.

In kvm_free_stage2_pgd() we check the stage2 PGD before holding
the lock and proceed to take the lock if it is valid. And we unmap
the page tables, followed by releasing the lock. We reset the PGD
only after dropping this lock, which could cause a race condition
where another thread waiting on or even holding the lock, could
potentially see that the PGD is still valid and proceed to perform
a stage2 operation and later encounter a NULL PGD.

[223090.242280] Unable to handle kernel NULL pointer dereference at
virtual address 00000040
[223090.262330] PC is at unmap_stage2_range+0x8c/0x428
[223090.262332] LR is at kvm_unmap_hva_handler+0x2c/0x3c
[223090.262531] Call trace:
[223090.262533] [] unmap_stage2_range+0x8c/0x428
[223090.262535] [] kvm_unmap_hva_handler+0x2c/0x3c
[223090.262537] [] handle_hva_to_gpa+0xb0/0x104
[223090.262539] [] kvm_unmap_hva+0x5c/0xbc
[223090.262543] []
kvm_mmu_notifier_invalidate_page+0x50/0x8c
[223090.262547] []
__mmu_notifier_invalidate_page+0x5c/0x84
[223090.262551] [] try_to_unmap_one+0x1d0/0x4a0
[223090.262553] [] rmap_walk+0x1cc/0x2e0
[223090.262555] [] try_to_unmap+0x74/0xa4
[223090.262557] [] migrate_pages+0x31c/0x5ac
[223090.262561] [] compact_zone+0x3fc/0x7ac
[223090.262563] [] compact_zone_order+0x94/0xb0
[223090.262564] [] try_to_compact_pages+0x108/0x290
[223090.262569] [] __alloc_pages_direct_compact+0x70/0x1ac
[223090.262571] [] __alloc_pages_nodemask+0x434/0x9f4
[223090.262572] [] alloc_pages_vma+0x230/0x254
[223090.262574] [] do_huge_pmd_anonymous_page+0x114/0x538
[223090.262576] [] handle_mm_fault+0xd40/0x17a4
[223090.262577] [] __get_user_pages+0x12c/0x36c
[223090.262578] [] get_user_pages_unlocked+0xa4/0x1b8
[223090.262579] [] __gfn_to_pfn_memslot+0x280/0x31c
[223090.262580] [] gfn_to_pfn_prot+0x4c/0x5c
[223090.262582] [] kvm_handle_guest_abort+0x240/0x774
[223090.262584] [] handle_exit+0x11c/0x1ac
[223090.262586] [] kvm_arch_vcpu_ioctl_run+0x31c/0x648
[223090.262587] [] kvm_vcpu_ioctl+0x378/0x768
[223090.262590] [] do_vfs_ioctl+0x324/0x5a4
[223090.262591] [] SyS_ioctl+0x90/0xa4
[223090.262595] [] el0_svc_naked+0x38/0x3c

This patch moves the stage2 PGD manipulation under the lock.

Reported-by: Alexander Graf 
Cc: Mark Rutland 
Cc: Marc Zyngier 
Cc: Paolo Bonzini 
Cc: Radim Krčmář 
Reviewed-by: Christoffer Dall 
Reviewed-by: Marc Zyngier 
Signed-off-by: Suzuki K Poulose 
Signed-off-by: Christoffer Dall 
Signed-off-by: Greg Kroah-Hartman

powerpc/mm: Ensure cpumask update is ordered

2017-08-30T08:21:56+00:00

commit 1a92a80ad386a1a6e3b36d576d52a1a456394b70 upstream.

There is no guarantee that the various isync's involved with
the context switch will order the update of the CPU mask with
the first TLB entry for the new context being loaded by the HW.

Be safe here and add a memory barrier to order any subsequent
load/store which may bring entries into the TLB.

The corresponding barrier on the other side already exists as
pte updates use pte_xchg() which uses __cmpxchg_u64 which has
a sync after the atomic operation.

Cc: stable@vger.kernel.org
Signed-off-by: Benjamin Herrenschmidt 
Reviewed-by: Nicholas Piggin 
[mpe: Add comments in the code]
[mpe: Backport to 4.12, minor context change]
Signed-off-by: Michael Ellerman 
Signed-off-by: Michael Ellerman 
Signed-off-by: Greg Kroah-Hartman

x86/mm: Fix use-after-free of ldt_struct

2017-08-30T08:21:51+00:00

commit ccd5b3235180eef3cfec337df1c8554ab151b5cc upstream.

The following commit:

  39a0526fb3f7 ("x86/mm: Factor out LDT init from context init")

renamed init_new_context() to init_new_context_ldt() and added a new
init_new_context() which calls init_new_context_ldt().  However, the
error code of init_new_context_ldt() was ignored.  Consequently, if a
memory allocation in alloc_ldt_struct() failed during a fork(), the
->context.ldt of the new task remained the same as that of the old task
(due to the memcpy() in dup_mm()).  ldt_struct's are not intended to be
shared, so a use-after-free occurred after one task exited.

Fix the bug by making init_new_context() pass through the error code of
init_new_context_ldt().

This bug was found by syzkaller, which encountered the following splat:

    BUG: KASAN: use-after-free in free_ldt_struct.part.2+0x10a/0x150 arch/x86/kernel/ldt.c:116
    Read of size 4 at addr ffff88006d2cb7c8 by task kworker/u9:0/3710

    CPU: 1 PID: 3710 Comm: kworker/u9:0 Not tainted 4.13.0-rc4-next-20170811 #2
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
    Call Trace:
     __dump_stack lib/dump_stack.c:16 [inline]
     dump_stack+0x194/0x257 lib/dump_stack.c:52
     print_address_description+0x73/0x250 mm/kasan/report.c:252
     kasan_report_error mm/kasan/report.c:351 [inline]
     kasan_report+0x24e/0x340 mm/kasan/report.c:409
     __asan_report_load4_noabort+0x14/0x20 mm/kasan/report.c:429
     free_ldt_struct.part.2+0x10a/0x150 arch/x86/kernel/ldt.c:116
     free_ldt_struct arch/x86/kernel/ldt.c:173 [inline]
     destroy_context_ldt+0x60/0x80 arch/x86/kernel/ldt.c:171
     destroy_context arch/x86/include/asm/mmu_context.h:157 [inline]
     __mmdrop+0xe9/0x530 kernel/fork.c:889
     mmdrop include/linux/sched/mm.h:42 [inline]
     exec_mmap fs/exec.c:1061 [inline]
     flush_old_exec+0x173c/0x1ff0 fs/exec.c:1291
     load_elf_binary+0x81f/0x4ba0 fs/binfmt_elf.c:855
     search_binary_handler+0x142/0x6b0 fs/exec.c:1652
     exec_binprm fs/exec.c:1694 [inline]
     do_execveat_common.isra.33+0x1746/0x22e0 fs/exec.c:1816
     do_execve+0x31/0x40 fs/exec.c:1860
     call_usermodehelper_exec_async+0x457/0x8f0 kernel/umh.c:100
     ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:431

    Allocated by task 3700:
     save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:59
     save_stack+0x43/0xd0 mm/kasan/kasan.c:447
     set_track mm/kasan/kasan.c:459 [inline]
     kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:551
     kmem_cache_alloc_trace+0x136/0x750 mm/slab.c:3627
     kmalloc include/linux/slab.h:493 [inline]
     alloc_ldt_struct+0x52/0x140 arch/x86/kernel/ldt.c:67
     write_ldt+0x7b7/0xab0 arch/x86/kernel/ldt.c:277
     sys_modify_ldt+0x1ef/0x240 arch/x86/kernel/ldt.c:307
     entry_SYSCALL_64_fastpath+0x1f/0xbe

    Freed by task 3700:
     save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:59
     save_stack+0x43/0xd0 mm/kasan/kasan.c:447
     set_track mm/kasan/kasan.c:459 [inline]
     kasan_slab_free+0x71/0xc0 mm/kasan/kasan.c:524
     __cache_free mm/slab.c:3503 [inline]
     kfree+0xca/0x250 mm/slab.c:3820
     free_ldt_struct.part.2+0xdd/0x150 arch/x86/kernel/ldt.c:121
     free_ldt_struct arch/x86/kernel/ldt.c:173 [inline]
     destroy_context_ldt+0x60/0x80 arch/x86/kernel/ldt.c:171
     destroy_context arch/x86/include/asm/mmu_context.h:157 [inline]
     __mmdrop+0xe9/0x530 kernel/fork.c:889
     mmdrop include/linux/sched/mm.h:42 [inline]
     __mmput kernel/fork.c:916 [inline]
     mmput+0x541/0x6e0 kernel/fork.c:927
     copy_process.part.36+0x22e1/0x4af0 kernel/fork.c:1931
     copy_process kernel/fork.c:1546 [inline]
     _do_fork+0x1ef/0xfb0 kernel/fork.c:2025
     SYSC_clone kernel/fork.c:2135 [inline]
     SyS_clone+0x37/0x50 kernel/fork.c:2129
     do_syscall_64+0x26c/0x8c0 arch/x86/entry/common.c:287
     return_from_SYSCALL_64+0x0/0x7a

Here is a C reproducer:

    #include 
    #include 
    #include 
    #include 
    #include 
    #include 
    #include 

    static void *fork_thread(void *_arg)
    {
        fork();
    }

    int main(void)
    {
        struct user_desc desc = { .entry_number = 8191 };

        syscall(__NR_modify_ldt, 1, &desc, sizeof(desc));

        for (;;) {
            if (fork() == 0) {
                pthread_t t;

                srand(getpid());
                pthread_create(&t, NULL, fork_thread, NULL);
                usleep(rand() % 10000);
                syscall(__NR_exit_group, 0);
            }
            wait(NULL);
        }
    }

Note: the reproducer takes advantage of the fact that alloc_ldt_struct()
may use vmalloc() to allocate a large ->entries array, and after
commit:

  5d17a73a2ebe ("vmalloc: back off when the current task is killed")

it is possible for userspace to fail a task's vmalloc() by
sending a fatal signal, e.g. via exit_group().  It would be more
difficult to reproduce this bug on kernels without that commit.

This bug only affected kernels with CONFIG_MODIFY_LDT_SYSCALL=y.

Signed-off-by: Eric Biggers 
Acked-by: Dave Hansen 
Cc: Andrew Morton 
Cc: Andy Lutomirski 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: Christoph Hellwig 
Cc: Denys Vlasenko 
Cc: Dmitry Vyukov 
Cc: Linus Torvalds 
Cc: Michal Hocko 
Cc: Peter Zijlstra 
Cc: Rik van Riel 
Cc: Tetsuo Handa 
Cc: Thomas Gleixner 
Cc: linux-mm@kvack.org
Fixes: 39a0526fb3f7 ("x86/mm: Factor out LDT init from context init")
Link: http://lkml.kernel.org/r/20170824175029.76040-1-ebiggers3@gmail.com
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

perf/x86/intel/rapl: Make package handling more robust

2017-08-30T08:21:50+00:00

commit dd86e373e09fb16b83e8adf5c48c421a4ca76468 upstream.

The package management code in RAPL relies on package mapping being
available before a CPU is started. This changed with:

  9d85eb9119f4 ("x86/smpboot: Make logical package management more robust")

because the ACPI/BIOS information turned out to be unreliable, but that
left RAPL in broken state. This was not noticed because on a regular boot
all CPUs are online before RAPL is initialized.

A possible fix would be to reintroduce the mess which allocates a package
data structure in CPU prepare and when it turns out to already exist in
starting throw it away later in the CPU online callback. But that's a
horrible hack and not required at all because RAPL becomes functional for
perf only in the CPU online callback. That's correct because user space is
not yet informed about the CPU being onlined, so nothing caan rely on RAPL
being available on that particular CPU.

Move the allocation to the CPU online callback and simplify the hotplug
handling. At this point the package mapping is established and correct.

This also adds a missing check for available package data in the
event_init() function.

Reported-by: Yasuaki Ishimatsu 
Signed-off-by: Thomas Gleixner 
Cc: Alexander Shishkin 
Cc: Arnaldo Carvalho de Melo 
Cc: Jiri Olsa 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Sebastian Siewior 
Cc: Stephane Eranian 
Cc: Vince Weaver 
Fixes: 9d85eb9119f4 ("x86/smpboot: Make logical package management more robust")
Link: http://lkml.kernel.org/r/20170131230141.212593966@linutronix.de
Signed-off-by: Ingo Molnar 
[ jwang: backport to 4.9 fix Null pointer deref during hotplug cpu.]
Signed-off-by: Jack Wang 
Signed-off-by: Greg Kroah-Hartman

ARCv2: PAE40: Explicitly set MSB counterpart of SLC region ops addresses

2017-08-30T08:21:46+00:00

commit 7d79cee2c6540ea64dd917a14e2fd63d4ac3d3c0 upstream.

It is necessary to explicitly set both SLC_AUX_RGN_START1 and SLC_AUX_RGN_END1
which hold MSB bits of the physical address correspondingly of region start
and end otherwise SLC region operation is executed in unpredictable manner

Without this patch, SLC flushes on HSDK (IOC disabled) were taking
seconds.

Reported-by: Vladimir Kondratiev 
Signed-off-by: Alexey Brodkin 
Signed-off-by: Vineet Gupta 
[vgupta: PAR40 regs only written if PAE40 exist]
Signed-off-by: Greg Kroah-Hartman