4.14-stable patches

added patches:
	kvm-x86-fix-wrong-macro-references-of-x86_cr0_pg_bit-and-x86_cr4_pae_bit-in-kvm_valid_sregs.patch
	kvm-x86-remove-warn_on-for-when-vm_munmap-fails.patch

diff --git a/queue-4.14/kvm-x86-fix-wrong-macro-references-of-x86_cr0_pg_bit-and-x86_cr4_pae_bit-in-kvm_valid_sregs.patch b/queue-4.14/kvm-x86-fix-wrong-macro-references-of-x86_cr0_pg_bit-and-x86_cr4_pae_bit-in-kvm_valid_sregs.patch
new file mode 100644 (file)
index 0000000..c6330e5
--- /dev/null
+++ b/queue-4.14/kvm-x86-fix-wrong-macro-references-of-x86_cr0_pg_bit-and-x86_cr4_pae_bit-in-kvm_valid_sregs.patch
@@ -0,0 +1,47 @@
+From 37b95951c58fdf08dc10afa9d02066ed9f176fb5 Mon Sep 17 00:00:00 2001
+From: Tianyu Lan <lantianyu1986@gmail.com>
+Date: Tue, 16 Jan 2018 17:34:07 +0800
+Subject: KVM/x86: Fix wrong macro references of X86_CR0_PG_BIT and X86_CR4_PAE_BIT in kvm_valid_sregs()
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Tianyu Lan <lantianyu1986@gmail.com>
+
+commit 37b95951c58fdf08dc10afa9d02066ed9f176fb5 upstream.
+
+kvm_valid_sregs() should use X86_CR0_PG and X86_CR4_PAE to check bit
+status rather than X86_CR0_PG_BIT and X86_CR4_PAE_BIT. This patch is
+to fix it.
+
+Fixes: f29810335965a(KVM/x86: Check input paging mode when cs.l is set)
+Reported-by: Jeremi Piotrowski <jeremi.piotrowski@gmail.com>
+Cc: Paolo Bonzini <pbonzini@redhat.com>
+Cc: Radim Krčmář <rkrcmar@redhat.com>
+Signed-off-by: Tianyu Lan <Tianyu.Lan@microsoft.com>
+Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
+Signed-off-by: Jack Wang <jinpu.wang@profitbricks.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/kvm/x86.c |    4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/arch/x86/kvm/x86.c
++++ b/arch/x86/kvm/x86.c
+@@ -7482,13 +7482,13 @@ EXPORT_SYMBOL_GPL(kvm_task_switch);
+ 
+ int kvm_valid_sregs(struct kvm_vcpu *vcpu, struct kvm_sregs *sregs)
+ {
+-      if ((sregs->efer & EFER_LME) && (sregs->cr0 & X86_CR0_PG_BIT)) {
++      if ((sregs->efer & EFER_LME) && (sregs->cr0 & X86_CR0_PG)) {
+               /*
+                * When EFER.LME and CR0.PG are set, the processor is in
+                * 64-bit mode (though maybe in a 32-bit code segment).
+                * CR4.PAE and EFER.LMA must be set.
+                */
+-              if (!(sregs->cr4 & X86_CR4_PAE_BIT)
++              if (!(sregs->cr4 & X86_CR4_PAE)
+                   || !(sregs->efer & EFER_LMA))
+                       return -EINVAL;
+       } else {

diff --git a/queue-4.14/kvm-x86-remove-warn_on-for-when-vm_munmap-fails.patch b/queue-4.14/kvm-x86-remove-warn_on-for-when-vm_munmap-fails.patch
new file mode 100644 (file)
index 0000000..71f630c
--- /dev/null
+++ b/queue-4.14/kvm-x86-remove-warn_on-for-when-vm_munmap-fails.patch
@@ -0,0 +1,58 @@
+From 103c763c72dd2df3e8c91f2d7ec88f98ed391111 Mon Sep 17 00:00:00 2001
+From: Eric Biggers <ebiggers@google.com>
+Date: Wed, 31 Jan 2018 17:30:21 -0800
+Subject: KVM/x86: remove WARN_ON() for when vm_munmap() fails
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Eric Biggers <ebiggers@google.com>
+
+commit 103c763c72dd2df3e8c91f2d7ec88f98ed391111 upstream.
+
+On x86, special KVM memslots such as the TSS region have anonymous
+memory mappings created on behalf of userspace, and these mappings are
+removed when the VM is destroyed.
+
+It is however possible for removing these mappings via vm_munmap() to
+fail.  This can most easily happen if the thread receives SIGKILL while
+it's waiting to acquire ->mmap_sem.   This triggers the 'WARN_ON(r < 0)'
+in __x86_set_memory_region().  syzkaller was able to hit this, using
+'exit()' to send the SIGKILL.  Note that while the vm_munmap() failure
+results in the mapping not being removed immediately, it is not leaked
+forever but rather will be freed when the process exits.
+
+It's not really possible to handle this failure properly, so almost
+every other caller of vm_munmap() doesn't check the return value.  It's
+a limitation of having the kernel manage these mappings rather than
+userspace.
+
+So just remove the WARN_ON() so that users can't spam the kernel log
+with this warning.
+
+Fixes: f0d648bdf0a5 ("KVM: x86: map/unmap private slots in __x86_set_memory_region")
+Reported-by: syzbot <syzkaller@googlegroups.com>
+Signed-off-by: Eric Biggers <ebiggers@google.com>
+Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
+Signed-off-by: Jack Wang <jinpu.wang@profitbricks.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/kvm/x86.c |    6 ++----
+ 1 file changed, 2 insertions(+), 4 deletions(-)
+
+--- a/arch/x86/kvm/x86.c
++++ b/arch/x86/kvm/x86.c
+@@ -8251,10 +8251,8 @@ int __x86_set_memory_region(struct kvm *
+                       return r;
+       }
+ 
+-      if (!size) {
+-              r = vm_munmap(old.userspace_addr, old.npages * PAGE_SIZE);
+-              WARN_ON(r < 0);
+-      }
++      if (!size)
++              vm_munmap(old.userspace_addr, old.npages * PAGE_SIZE);
+ 
+       return 0;
+ }

diff --git a/queue-4.14/series b/queue-4.14/series
index 228b114340e14b32e76b9a154a16ac0474380403..270d5d55ca23872259964131ae6446281aa69c8d 100644 (file)
--- a/queue-4.14/series
+++ b/queue-4.14/series
@@ -101,3 +101,5 @@ kvm-x86-move-lapic-initialization-after-vmcs-creation.patch
 kvm-vmx-optimize-vmx_vcpu_run-and-svm_vcpu_run-by-marking-the-rdmsr-path-as-unlikely.patch
 kvm-x86-fix-vcpu-initialization-with-userspace-lapic.patch
 pci-aspm-deal-with-missing-root-ports-in-link-state-handling.patch
+kvm-x86-fix-wrong-macro-references-of-x86_cr0_pg_bit-and-x86_cr4_pae_bit-in-kvm_valid_sregs.patch
+kvm-x86-remove-warn_on-for-when-vm_munmap-fails.patch