From: Greg Kroah-Hartman Date: Sun, 9 Feb 2020 12:43:31 +0000 (+0100) Subject: 4.19-stable patches X-Git-Tag: v4.19.103~62 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=82f09440ac18f0b40080b49081b8641cc8a6989c;p=thirdparty%2Fkernel%2Fstable-queue.git 4.19-stable patches added patches: kvm-s390-do-not-clobber-registers-during-guest-reset-store-status.patch kvm-x86-don-t-let-userspace-set-host-reserved-cr4-bits.patch kvm-x86-free-wbinvd_dirty_mask-if-vcpu-creation-fails.patch x86-kvm-be-careful-not-to-clear-kvm_vcpu_flush_tlb-bit.patch --- diff --git a/queue-4.19/kvm-s390-do-not-clobber-registers-during-guest-reset-store-status.patch b/queue-4.19/kvm-s390-do-not-clobber-registers-during-guest-reset-store-status.patch new file mode 100644 index 00000000000..1861fcfa0be --- /dev/null +++ b/queue-4.19/kvm-s390-do-not-clobber-registers-during-guest-reset-store-status.patch @@ -0,0 +1,51 @@ +From 55680890ea78be0df5e1384989f1be835043c084 Mon Sep 17 00:00:00 2001 +From: Christian Borntraeger +Date: Fri, 31 Jan 2020 05:02:00 -0500 +Subject: KVM: s390: do not clobber registers during guest reset/store status + +From: Christian Borntraeger + +commit 55680890ea78be0df5e1384989f1be835043c084 upstream. + +The initial CPU reset clobbers the userspace fpc and the store status +ioctl clobbers the guest acrs + fpr. As these calls are only done via +ioctl (and not via vcpu_run), no CPU context is loaded, so we can (and +must) act directly on the sync regs, not on the thread context. + +Cc: stable@kernel.org +Fixes: e1788bb995be ("KVM: s390: handle floating point registers in the run ioctl not in vcpu_put/load") +Fixes: 31d8b8d41a7e ("KVM: s390: handle access registers in the run ioctl not in vcpu_put/load") +Signed-off-by: Christian Borntraeger +Reviewed-by: David Hildenbrand +Reviewed-by: Cornelia Huck +Signed-off-by: Janosch Frank +Link: https://lore.kernel.org/r/20200131100205.74720-2-frankja@linux.ibm.com +Signed-off-by: Christian Borntraeger +Signed-off-by: Greg Kroah-Hartman + +--- + arch/s390/kvm/kvm-s390.c | 6 ++---- + 1 file changed, 2 insertions(+), 4 deletions(-) + +--- a/arch/s390/kvm/kvm-s390.c ++++ b/arch/s390/kvm/kvm-s390.c +@@ -2564,9 +2564,7 @@ static void kvm_s390_vcpu_initial_reset( + vcpu->arch.sie_block->gcr[14] = CR14_UNUSED_32 | + CR14_UNUSED_33 | + CR14_EXTERNAL_DAMAGE_SUBMASK; +- /* make sure the new fpc will be lazily loaded */ +- save_fpu_regs(); +- current->thread.fpu.fpc = 0; ++ vcpu->run->s.regs.fpc = 0; + vcpu->arch.sie_block->gbea = 1; + vcpu->arch.sie_block->pp = 0; + vcpu->arch.sie_block->fpf &= ~FPF_BPBC; +@@ -3994,7 +3992,7 @@ long kvm_arch_vcpu_ioctl(struct file *fi + switch (ioctl) { + case KVM_S390_STORE_STATUS: + idx = srcu_read_lock(&vcpu->kvm->srcu); +- r = kvm_s390_vcpu_store_status(vcpu, arg); ++ r = kvm_s390_store_status_unloaded(vcpu, arg); + srcu_read_unlock(&vcpu->kvm->srcu, idx); + break; + case KVM_S390_SET_INITIAL_PSW: { diff --git a/queue-4.19/kvm-x86-don-t-let-userspace-set-host-reserved-cr4-bits.patch b/queue-4.19/kvm-x86-don-t-let-userspace-set-host-reserved-cr4-bits.patch new file mode 100644 index 00000000000..c31966f208b --- /dev/null +++ b/queue-4.19/kvm-x86-don-t-let-userspace-set-host-reserved-cr4-bits.patch @@ -0,0 +1,122 @@ +From b11306b53b2540c6ba068c4deddb6a17d9f8d95b Mon Sep 17 00:00:00 2001 +From: Sean Christopherson +Date: Tue, 10 Dec 2019 14:44:13 -0800 +Subject: KVM: x86: Don't let userspace set host-reserved cr4 bits + +From: Sean Christopherson + +commit b11306b53b2540c6ba068c4deddb6a17d9f8d95b upstream. + +Calculate the host-reserved cr4 bits at runtime based on the system's +capabilities (using logic similar to __do_cpuid_func()), and use the +dynamically generated mask for the reserved bit check in kvm_set_cr4() +instead using of the static CR4_RESERVED_BITS define. This prevents +userspace from "enabling" features in cr4 that are not supported by the +system, e.g. by ignoring KVM_GET_SUPPORTED_CPUID and specifying a bogus +CPUID for the vCPU. + +Allowing userspace to set unsupported bits in cr4 can lead to a variety +of undesirable behavior, e.g. failed VM-Enter, and in general increases +KVM's attack surface. A crafty userspace can even abuse CR4.LA57 to +induce an unchecked #GP on a WRMSR. + +On a platform without LA57 support: + + KVM_SET_CPUID2 // CPUID_7_0_ECX.LA57 = 1 + KVM_SET_SREGS // CR4.LA57 = 1 + KVM_SET_MSRS // KERNEL_GS_BASE = 0x0004000000000000 + KVM_RUN + +leads to a #GP when writing KERNEL_GS_BASE into hardware: + + unchecked MSR access error: WRMSR to 0xc0000102 (tried to write 0x0004000000000000) + at rIP: 0xffffffffa00f239a (vmx_prepare_switch_to_guest+0x10a/0x1d0 [kvm_intel]) + Call Trace: + kvm_arch_vcpu_ioctl_run+0x671/0x1c70 [kvm] + kvm_vcpu_ioctl+0x36b/0x5d0 [kvm] + do_vfs_ioctl+0xa1/0x620 + ksys_ioctl+0x66/0x70 + __x64_sys_ioctl+0x16/0x20 + do_syscall_64+0x4c/0x170 + entry_SYSCALL_64_after_hwframe+0x44/0xa9 + RIP: 0033:0x7fc08133bf47 + +Note, the above sequence fails VM-Enter due to invalid guest state. +Userspace can allow VM-Enter to succeed (after the WRMSR #GP) by adding +a KVM_SET_SREGS w/ CR4.LA57=0 after KVM_SET_MSRS, in which case KVM will +technically leak the host's KERNEL_GS_BASE into the guest. But, as +KERNEL_GS_BASE is a userspace-defined value/address, the leak is largely +benign as a malicious userspace would simply be exposing its own data to +the guest, and attacking a benevolent userspace would require multiple +bugs in the userspace VMM. + +Cc: stable@vger.kernel.org +Cc: Jun Nakajima +Signed-off-by: Sean Christopherson +Signed-off-by: Paolo Bonzini +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/kvm/x86.c | 35 ++++++++++++++++++++++++++++++++++- + 1 file changed, 34 insertions(+), 1 deletion(-) + +--- a/arch/x86/kvm/x86.c ++++ b/arch/x86/kvm/x86.c +@@ -92,6 +92,8 @@ u64 __read_mostly efer_reserved_bits = ~ + static u64 __read_mostly efer_reserved_bits = ~((u64)EFER_SCE); + #endif + ++static u64 __read_mostly cr4_reserved_bits = CR4_RESERVED_BITS; ++ + #define VM_STAT(x, ...) offsetof(struct kvm, stat.x), KVM_STAT_VM, ## __VA_ARGS__ + #define VCPU_STAT(x, ...) offsetof(struct kvm_vcpu, stat.x), KVM_STAT_VCPU, ## __VA_ARGS__ + +@@ -793,9 +795,38 @@ int kvm_set_xcr(struct kvm_vcpu *vcpu, u + } + EXPORT_SYMBOL_GPL(kvm_set_xcr); + ++static u64 kvm_host_cr4_reserved_bits(struct cpuinfo_x86 *c) ++{ ++ u64 reserved_bits = CR4_RESERVED_BITS; ++ ++ if (!cpu_has(c, X86_FEATURE_XSAVE)) ++ reserved_bits |= X86_CR4_OSXSAVE; ++ ++ if (!cpu_has(c, X86_FEATURE_SMEP)) ++ reserved_bits |= X86_CR4_SMEP; ++ ++ if (!cpu_has(c, X86_FEATURE_SMAP)) ++ reserved_bits |= X86_CR4_SMAP; ++ ++ if (!cpu_has(c, X86_FEATURE_FSGSBASE)) ++ reserved_bits |= X86_CR4_FSGSBASE; ++ ++ if (!cpu_has(c, X86_FEATURE_PKU)) ++ reserved_bits |= X86_CR4_PKE; ++ ++ if (!cpu_has(c, X86_FEATURE_LA57) && ++ !(cpuid_ecx(0x7) & bit(X86_FEATURE_LA57))) ++ reserved_bits |= X86_CR4_LA57; ++ ++ if (!cpu_has(c, X86_FEATURE_UMIP) && !kvm_x86_ops->umip_emulated()) ++ reserved_bits |= X86_CR4_UMIP; ++ ++ return reserved_bits; ++} ++ + static int kvm_valid_cr4(struct kvm_vcpu *vcpu, unsigned long cr4) + { +- if (cr4 & CR4_RESERVED_BITS) ++ if (cr4 & cr4_reserved_bits) + return -EINVAL; + + if (!guest_cpuid_has(vcpu, X86_FEATURE_XSAVE) && (cr4 & X86_CR4_OSXSAVE)) +@@ -8864,6 +8895,8 @@ int kvm_arch_hardware_setup(void) + if (r != 0) + return r; + ++ cr4_reserved_bits = kvm_host_cr4_reserved_bits(&boot_cpu_data); ++ + if (kvm_has_tsc_control) { + /* + * Make sure the user can only configure tsc_khz values that diff --git a/queue-4.19/kvm-x86-free-wbinvd_dirty_mask-if-vcpu-creation-fails.patch b/queue-4.19/kvm-x86-free-wbinvd_dirty_mask-if-vcpu-creation-fails.patch new file mode 100644 index 00000000000..bd5c72d6077 --- /dev/null +++ b/queue-4.19/kvm-x86-free-wbinvd_dirty_mask-if-vcpu-creation-fails.patch @@ -0,0 +1,37 @@ +From 16be9ddea268ad841457a59109963fff8c9de38d Mon Sep 17 00:00:00 2001 +From: Sean Christopherson +Date: Wed, 18 Dec 2019 13:54:48 -0800 +Subject: KVM: x86: Free wbinvd_dirty_mask if vCPU creation fails + +From: Sean Christopherson + +commit 16be9ddea268ad841457a59109963fff8c9de38d upstream. + +Free the vCPU's wbinvd_dirty_mask if vCPU creation fails after +kvm_arch_vcpu_init(), e.g. when installing the vCPU's file descriptor. +Do the freeing by calling kvm_arch_vcpu_free() instead of open coding +the freeing. This adds a likely superfluous, but ultimately harmless, +call to kvmclock_reset(), which only clears vcpu->arch.pv_time_enabled. +Using kvm_arch_vcpu_free() allows for additional cleanup in the future. + +Fixes: f5f48ee15c2ee ("KVM: VMX: Execute WBINVD to keep data consistency with assigned devices") +Cc: stable@vger.kernel.org +Signed-off-by: Sean Christopherson +Signed-off-by: Paolo Bonzini +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/kvm/x86.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/arch/x86/kvm/x86.c ++++ b/arch/x86/kvm/x86.c +@@ -8702,7 +8702,7 @@ void kvm_arch_vcpu_destroy(struct kvm_vc + kvm_mmu_unload(vcpu); + vcpu_put(vcpu); + +- kvm_x86_ops->vcpu_free(vcpu); ++ kvm_arch_vcpu_free(vcpu); + } + + void kvm_vcpu_reset(struct kvm_vcpu *vcpu, bool init_event) diff --git a/queue-4.19/series b/queue-4.19/series index c6feaab650d..42c10a2f320 100644 --- a/queue-4.19/series +++ b/queue-4.19/series @@ -135,3 +135,7 @@ kvm-x86-protect-msr-based-index-computations-in-fixed_msr_to_seg_unit-from-spect kvm-x86-fix-potential-put_fpu-w-o-load_fpu-on-mpx-platform.patch kvm-ppc-book3s-hv-uninit-vcpu-if-vcore-creation-fails.patch kvm-ppc-book3s-pr-free-shared-page-if-mmu-initialization-fails.patch +x86-kvm-be-careful-not-to-clear-kvm_vcpu_flush_tlb-bit.patch +kvm-x86-don-t-let-userspace-set-host-reserved-cr4-bits.patch +kvm-x86-free-wbinvd_dirty_mask-if-vcpu-creation-fails.patch +kvm-s390-do-not-clobber-registers-during-guest-reset-store-status.patch diff --git a/queue-4.19/x86-kvm-be-careful-not-to-clear-kvm_vcpu_flush_tlb-bit.patch b/queue-4.19/x86-kvm-be-careful-not-to-clear-kvm_vcpu_flush_tlb-bit.patch new file mode 100644 index 00000000000..ad0213af469 --- /dev/null +++ b/queue-4.19/x86-kvm-be-careful-not-to-clear-kvm_vcpu_flush_tlb-bit.patch @@ -0,0 +1,39 @@ +From 8c6de56a42e0c657955e12b882a81ef07d1d073e Mon Sep 17 00:00:00 2001 +From: Boris Ostrovsky +Date: Wed, 30 Oct 2019 19:01:31 +0000 +Subject: x86/kvm: Be careful not to clear KVM_VCPU_FLUSH_TLB bit + +From: Boris Ostrovsky + +commit 8c6de56a42e0c657955e12b882a81ef07d1d073e upstream. + +kvm_steal_time_set_preempted() may accidentally clear KVM_VCPU_FLUSH_TLB +bit if it is called more than once while VCPU is preempted. + +This is part of CVE-2019-3016. + +(This bug was also independently discovered by Jim Mattson +) + +Signed-off-by: Boris Ostrovsky +Reviewed-by: Joao Martins +Cc: stable@vger.kernel.org +Signed-off-by: Paolo Bonzini +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/kvm/x86.c | 3 +++ + 1 file changed, 3 insertions(+) + +--- a/arch/x86/kvm/x86.c ++++ b/arch/x86/kvm/x86.c +@@ -3244,6 +3244,9 @@ static void kvm_steal_time_set_preempted + if (!(vcpu->arch.st.msr_val & KVM_MSR_ENABLED)) + return; + ++ if (vcpu->arch.st.steal.preempted) ++ return; ++ + vcpu->arch.st.steal.preempted = KVM_VCPU_PREEMPTED; + + kvm_write_guest_offset_cached(vcpu->kvm, &vcpu->arch.st.stime,