linux-toradex.git/arch/x86, branch v4.4.35

x86/kexec: add -fno-PIE

2016-11-26T08:54:52+00:00

commit 90944e40ba1838de4b2a9290cf273f9d76bd3bdd upstream.

If the gcc is configured to do -fPIE by default then the build aborts
later with:
| Unsupported relocation type: unknown type rel type name (29)

Tagging it stable so it is possible to compile recent stable kernels as
well.

Signed-off-by: Sebastian Andrzej Siewior 
Signed-off-by: Michal Marek 
Signed-off-by: Greg Kroah-Hartman

KVM: Disable irq while unregistering user notifier

2016-11-26T08:54:52+00:00

commit 1650b4ebc99da4c137bfbfc531be4a2405f951dd upstream.

Function user_notifier_unregister should be called only once for each
registered user notifier.

Function kvm_arch_hardware_disable can be executed from an IPI context
which could cause a race condition with a VCPU returning to user mode
and attempting to unregister the notifier.

Signed-off-by: Ignacio Alvarado 
Fixes: 18863bdd60f8 ("KVM: x86 shared msr infrastructure")
Reviewed-by: Paolo Bonzini 
Signed-off-by: Radim Krčmář 
Signed-off-by: Greg Kroah-Hartman

KVM: x86: fix missed SRCU usage in kvm_lapic_set_vapic_addr

2016-11-26T08:54:51+00:00

commit 7301d6abaea926d685832f7e1f0c37dd206b01f4 upstream.

Reported by syzkaller:

    [ INFO: suspicious RCU usage. ]
    4.9.0-rc4+ #47 Not tainted
    -------------------------------
    ./include/linux/kvm_host.h:536 suspicious rcu_dereference_check() usage!

    stack backtrace:
    CPU: 1 PID: 6679 Comm: syz-executor Not tainted 4.9.0-rc4+ #47
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
     ffff880039e2f6d0 ffffffff81c2e46b ffff88003e3a5b40 0000000000000000
     0000000000000001 ffffffff83215600 ffff880039e2f700 ffffffff81334ea9
     ffffc9000730b000 0000000000000004 ffff88003c4f8420 ffff88003d3f8000
    Call Trace:
     [<     inline     >] __dump_stack lib/dump_stack.c:15
     [] dump_stack+0xb3/0x118 lib/dump_stack.c:51
     [] lockdep_rcu_suspicious+0x139/0x180 kernel/locking/lockdep.c:4445
     [<     inline     >] __kvm_memslots include/linux/kvm_host.h:534
     [<     inline     >] kvm_memslots include/linux/kvm_host.h:541
     [] kvm_gfn_to_hva_cache_init+0xa1e/0xce0 virt/kvm/kvm_main.c:1941
     [] kvm_lapic_set_vapic_addr+0xed/0x140 arch/x86/kvm/lapic.c:2217

Reported-by: Dmitry Vyukov 
Fixes: fda4e2e85589191b123d31cdc21fd33ee70f50fd
Cc: Andrew Honig 
Signed-off-by: Paolo Bonzini 
Reviewed-by: David Hildenbrand 
Signed-off-by: Radim Krčmář 
Signed-off-by: Greg Kroah-Hartman

x86/cpu/AMD: Fix cpu_llc_id for AMD Fam17h systems

2016-11-26T08:54:51+00:00

commit b0b6e86846093c5f8820386bc01515f857dd8faa upstream.

cpu_llc_id (Last Level Cache ID) derivation on AMD Fam17h has an
underflow bug when extracting the socket_id value. It starts from 0
so subtracting 1 from it will result in an invalid value. This breaks
scheduling topology later on since the cpu_llc_id will be incorrect.

For example, the the cpu_llc_id of the *other* CPU in the loops in
set_cpu_sibling_map() underflows and we're generating the funniest
thread_siblings masks and then when I run 8 threads of nbench, they get
spread around the LLC domains in a very strange pattern which doesn't
give you the normal scheduling spread one would expect for performance.

Other things like EDAC use cpu_llc_id so they will be b0rked too.

So, the APIC ID is preset in APICx020 for bits 3 and above: they contain
the core complex, node and socket IDs.

The LLC is at the core complex level so we can find a unique cpu_llc_id
by right shifting the APICID by 3 because then the least significant bit
will be the Core Complex ID.

Tested-by: Borislav Petkov 
Signed-off-by: Yazen Ghannam 
[ Cleaned up and extended the commit message. ]
Signed-off-by: Borislav Petkov 
Acked-by: Thomas Gleixner 
Cc: Aravind Gopalakrishnan 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Fixes: 3849e91f571d ("x86/AMD: Fix last level cache topology for AMD Fam17h systems")
Link: http://lkml.kernel.org/r/20161108083506.rvqb5h4chrcptj7d@pd.tnic
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

kvm: x86: Check memopp before dereference (CVE-2016-8630)

2016-11-10T15:36:37+00:00

commit d9092f52d7e61dd1557f2db2400ddb430e85937e upstream.

Commit 41061cdb98 ("KVM: emulate: do not initialize memopp") removes a
check for non-NULL under incorrect assumptions. An undefined instruction
with a ModR/M byte with Mod=0 and R/M-5 (e.g. 0xc7 0x15) will attempt
to dereference a null pointer here.

Fixes: 41061cdb98a0bec464278b4db8e894a3121671f5
Message-Id: <1477592752-126650-2-git-send-email-osh@google.com>
Signed-off-by: Owen Hofmann 
Signed-off-by: Paolo Bonzini 
Signed-off-by: Greg Kroah-Hartman

x86/xen: fix upper bound of pmd loop in xen_cleanhighmap()

2016-11-10T15:36:36+00:00

commit 1cf38741308c64d08553602b3374fb39224eeb5a upstream.

xen_cleanhighmap() is operating on level2_kernel_pgt only. The upper
bound of the loop setting non-kernel-image entries to zero should not
exceed the size of level2_kernel_pgt.

Reported-by: Linus Torvalds 
Signed-off-by: Juergen Gross 
Signed-off-by: David Vrabel 
Signed-off-by: Greg Kroah-Hartman

KVM: x86: fix wbinvd_dirty_mask use-after-free

2016-11-10T15:36:34+00:00

commit bd768e146624cbec7122ed15dead8daa137d909d upstream.

vcpu->arch.wbinvd_dirty_mask may still be used after freeing it,
corrupting memory. For example, the following call trace may set a bit
in an already freed cpu mask:
    kvm_arch_vcpu_load
    vcpu_load
    vmx_free_vcpu_nested
    vmx_free_vcpu
    kvm_arch_vcpu_free

Fix this by deferring freeing of wbinvd_dirty_mask.

Signed-off-by: Ido Yariv 
Reviewed-by: Paolo Bonzini 
Signed-off-by: Radim Krčmář 
Signed-off-by: Greg Kroah-Hartman

Fix potential infoleak in older kernels

2016-11-10T15:36:34+00:00

Not upstream as it is not needed there.

So a patch something like this might be a safe way to fix the
potential infoleak in older kernels.

THIS IS UNTESTED. It's a very obvious patch, though, so if it compiles
it probably works. It just initializes the output variable with 0 in
the inline asm description, instead of doing it in the exception
handler.

It will generate slightly worse code (a few unnecessary ALU
operations), but it doesn't have any interactions with the exception
handler implementation.


Signed-off-by: Greg Kroah-Hartman

Revert "fix minor infoleak in get_user_ex()"

2016-11-01T01:56:26+00:00

This reverts commit 9d25c78ec01c402dc56272693c44ef9d72ecdd2e which is
1c109fabbd51863475cd12ac206bdd249aee35af upstream

Cc: Al Viro 
Cc: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

Revert "x86/mm: Expand the exception table logic to allow new handling options"

2016-11-01T01:56:26+00:00

This reverts commit fcf5e5198b447969ed2a56ec335dae3c695a6b46 which is
548acf19234dbda5a52d5a8e7e205af46e9da840 upstream.

Cc: Tony Luck 
Cc: Borislav Petkov 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman