From: Greg Kroah-Hartman Date: Tue, 14 Apr 2020 14:42:07 +0000 (+0200) Subject: 4.9-stable patches X-Git-Tag: v4.19.116~66 X-Git-Url: http://git.ipfire.org/gitweb/index.cgi?a=commitdiff_plain;h=db692d1da887df8505347947571a115e1fb05146;p=thirdparty%2Fkernel%2Fstable-queue.git 4.9-stable patches added patches: btrfs-drop-block-from-cache-on-error-in-relocation.patch crypto-mxs-dcp-fix-scatterlist-linearization-for-hash.patch kvm-s390-vsie-fix-delivery-of-addressing-exceptions.patch kvm-s390-vsie-fix-region-1-asce-sanity-shadow-address-checks.patch kvm-vmx-always-vmclear-in-use-vmcses-during-crash-with-kexec-support.patch kvm-vmx-fix-crash-cleanup-when-kvm-wasn-t-used.patch kvm-x86-allocate-new-rmap-and-large-page-tracking-when-moving-memslot.patch --- diff --git a/queue-4.9/btrfs-drop-block-from-cache-on-error-in-relocation.patch b/queue-4.9/btrfs-drop-block-from-cache-on-error-in-relocation.patch new file mode 100644 index 00000000000..977f53f83bb --- /dev/null +++ b/queue-4.9/btrfs-drop-block-from-cache-on-error-in-relocation.patch @@ -0,0 +1,41 @@ +From 8e19c9732ad1d127b5575a10f4fbcacf740500ff Mon Sep 17 00:00:00 2001 +From: Josef Bacik +Date: Wed, 4 Mar 2020 11:18:23 -0500 +Subject: btrfs: drop block from cache on error in relocation + +From: Josef Bacik + +commit 8e19c9732ad1d127b5575a10f4fbcacf740500ff upstream. + +If we have an error while building the backref tree in relocation we'll +process all the pending edges and then free the node. However if we +integrated some edges into the cache we'll lose our link to those edges +by simply freeing this node, which means we'll leak memory and +references to any roots that we've found. + +Instead we need to use remove_backref_node(), which walks through all of +the edges that are still linked to this node and free's them up and +drops any root references we may be holding. + +CC: stable@vger.kernel.org # 4.9+ +Reviewed-by: Qu Wenruo +Signed-off-by: Josef Bacik +Reviewed-by: David Sterba +Signed-off-by: David Sterba +Signed-off-by: Greg Kroah-Hartman + +--- + fs/btrfs/relocation.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/fs/btrfs/relocation.c ++++ b/fs/btrfs/relocation.c +@@ -1185,7 +1185,7 @@ out: + free_backref_node(cache, lower); + } + +- free_backref_node(cache, node); ++ remove_backref_node(cache, node); + return ERR_PTR(err); + } + ASSERT(!node || !node->detached); diff --git a/queue-4.9/crypto-mxs-dcp-fix-scatterlist-linearization-for-hash.patch b/queue-4.9/crypto-mxs-dcp-fix-scatterlist-linearization-for-hash.patch new file mode 100644 index 00000000000..d2d871ba680 --- /dev/null +++ b/queue-4.9/crypto-mxs-dcp-fix-scatterlist-linearization-for-hash.patch @@ -0,0 +1,113 @@ +From fa03481b6e2e82355c46644147b614f18c7a8161 Mon Sep 17 00:00:00 2001 +From: Rosioru Dragos +Date: Tue, 25 Feb 2020 17:05:52 +0200 +Subject: crypto: mxs-dcp - fix scatterlist linearization for hash +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Rosioru Dragos + +commit fa03481b6e2e82355c46644147b614f18c7a8161 upstream. + +The incorrect traversal of the scatterlist, during the linearization phase +lead to computing the hash value of the wrong input buffer. +New implementation uses scatterwalk_map_and_copy() +to address this issue. + +Cc: +Fixes: 15b59e7c3733 ("crypto: mxs - Add Freescale MXS DCP driver") +Signed-off-by: Rosioru Dragos +Reviewed-by: Horia Geantă +Signed-off-by: Herbert Xu +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/crypto/mxs-dcp.c | 54 ++++++++++++++++++++++------------------------- + 1 file changed, 26 insertions(+), 28 deletions(-) + +--- a/drivers/crypto/mxs-dcp.c ++++ b/drivers/crypto/mxs-dcp.c +@@ -25,6 +25,7 @@ + #include + #include + #include ++#include + + #define DCP_MAX_CHANS 4 + #define DCP_BUF_SZ PAGE_SIZE +@@ -621,49 +622,46 @@ static int dcp_sha_req_to_buf(struct cry + struct dcp_async_ctx *actx = crypto_ahash_ctx(tfm); + struct dcp_sha_req_ctx *rctx = ahash_request_ctx(req); + struct hash_alg_common *halg = crypto_hash_alg_common(tfm); +- const int nents = sg_nents(req->src); + + uint8_t *in_buf = sdcp->coh->sha_in_buf; + uint8_t *out_buf = sdcp->coh->sha_out_buf; + +- uint8_t *src_buf; +- + struct scatterlist *src; + +- unsigned int i, len, clen; ++ unsigned int i, len, clen, oft = 0; + int ret; + + int fin = rctx->fini; + if (fin) + rctx->fini = 0; + +- for_each_sg(req->src, src, nents, i) { +- src_buf = sg_virt(src); +- len = sg_dma_len(src); ++ src = req->src; ++ len = req->nbytes; + +- do { +- if (actx->fill + len > DCP_BUF_SZ) +- clen = DCP_BUF_SZ - actx->fill; +- else +- clen = len; ++ while (len) { ++ if (actx->fill + len > DCP_BUF_SZ) ++ clen = DCP_BUF_SZ - actx->fill; ++ else ++ clen = len; + +- memcpy(in_buf + actx->fill, src_buf, clen); +- len -= clen; +- src_buf += clen; +- actx->fill += clen; ++ scatterwalk_map_and_copy(in_buf + actx->fill, src, oft, clen, ++ 0); + +- /* +- * If we filled the buffer and still have some +- * more data, submit the buffer. +- */ +- if (len && actx->fill == DCP_BUF_SZ) { +- ret = mxs_dcp_run_sha(req); +- if (ret) +- return ret; +- actx->fill = 0; +- rctx->init = 0; +- } +- } while (len); ++ len -= clen; ++ oft += clen; ++ actx->fill += clen; ++ ++ /* ++ * If we filled the buffer and still have some ++ * more data, submit the buffer. ++ */ ++ if (len && actx->fill == DCP_BUF_SZ) { ++ ret = mxs_dcp_run_sha(req); ++ if (ret) ++ return ret; ++ actx->fill = 0; ++ rctx->init = 0; ++ } + } + + if (fin) { diff --git a/queue-4.9/kvm-s390-vsie-fix-delivery-of-addressing-exceptions.patch b/queue-4.9/kvm-s390-vsie-fix-delivery-of-addressing-exceptions.patch new file mode 100644 index 00000000000..20f8a30fd54 --- /dev/null +++ b/queue-4.9/kvm-s390-vsie-fix-delivery-of-addressing-exceptions.patch @@ -0,0 +1,50 @@ +From 4d4cee96fb7a3cc53702a9be8299bf525be4ee98 Mon Sep 17 00:00:00 2001 +From: David Hildenbrand +Date: Fri, 3 Apr 2020 17:30:47 +0200 +Subject: KVM: s390: vsie: Fix delivery of addressing exceptions + +From: David Hildenbrand + +commit 4d4cee96fb7a3cc53702a9be8299bf525be4ee98 upstream. + +Whenever we get an -EFAULT, we failed to read in guest 2 physical +address space. Such addressing exceptions are reported via a program +intercept to the nested hypervisor. + +We faked the intercept, we have to return to guest 2. Instead, right +now we would be returning -EFAULT from the intercept handler, eventually +crashing the VM. +the correct thing to do is to return 1 as rc == 1 is the internal +representation of "we have to go back into g2". + +Addressing exceptions can only happen if the g2->g3 page tables +reference invalid g2 addresses (say, either a table or the final page is +not accessible - so something that basically never happens in sane +environments. + +Identified by manual code inspection. + +Fixes: a3508fbe9dc6 ("KVM: s390: vsie: initial support for nested virtualization") +Cc: # v4.8+ +Signed-off-by: David Hildenbrand +Link: https://lore.kernel.org/r/20200403153050.20569-3-david@redhat.com +Reviewed-by: Claudio Imbrenda +Reviewed-by: Christian Borntraeger +[borntraeger@de.ibm.com: fix patch description] +Signed-off-by: Christian Borntraeger +Signed-off-by: Greg Kroah-Hartman + +--- + arch/s390/kvm/vsie.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/arch/s390/kvm/vsie.c ++++ b/arch/s390/kvm/vsie.c +@@ -947,6 +947,7 @@ static int vsie_run(struct kvm_vcpu *vcp + scb_s->iprcc = PGM_ADDRESSING; + scb_s->pgmilc = 4; + scb_s->gpsw.addr = __rewind_psw(scb_s->gpsw, 4); ++ rc = 1; + } + return rc; + } diff --git a/queue-4.9/kvm-s390-vsie-fix-region-1-asce-sanity-shadow-address-checks.patch b/queue-4.9/kvm-s390-vsie-fix-region-1-asce-sanity-shadow-address-checks.patch new file mode 100644 index 00000000000..697fcdb5ded --- /dev/null +++ b/queue-4.9/kvm-s390-vsie-fix-region-1-asce-sanity-shadow-address-checks.patch @@ -0,0 +1,56 @@ +From a1d032a49522cb5368e5dfb945a85899b4c74f65 Mon Sep 17 00:00:00 2001 +From: David Hildenbrand +Date: Fri, 3 Apr 2020 17:30:46 +0200 +Subject: KVM: s390: vsie: Fix region 1 ASCE sanity shadow address checks + +From: David Hildenbrand + +commit a1d032a49522cb5368e5dfb945a85899b4c74f65 upstream. + +In case we have a region 1 the following calculation +(31 + ((gmap->asce & _ASCE_TYPE_MASK) >> 2)*11) +results in 64. As shifts beyond the size are undefined the compiler is +free to use instructions like sllg. sllg will only use 6 bits of the +shift value (here 64) resulting in no shift at all. That means that ALL +addresses will be rejected. + +The can result in endless loops, e.g. when prefix cannot get mapped. + +Fixes: 4be130a08420 ("s390/mm: add shadow gmap support") +Tested-by: Janosch Frank +Reported-by: Janosch Frank +Cc: # v4.8+ +Signed-off-by: David Hildenbrand +Link: https://lore.kernel.org/r/20200403153050.20569-2-david@redhat.com +Reviewed-by: Claudio Imbrenda +Reviewed-by: Christian Borntraeger +[borntraeger@de.ibm.com: fix patch description, remove WARN_ON_ONCE] +Signed-off-by: Christian Borntraeger +Signed-off-by: Greg Kroah-Hartman + +--- + arch/s390/mm/gmap.c | 6 +++++- + 1 file changed, 5 insertions(+), 1 deletion(-) + +--- a/arch/s390/mm/gmap.c ++++ b/arch/s390/mm/gmap.c +@@ -759,14 +759,18 @@ static void gmap_call_notifier(struct gm + static inline unsigned long *gmap_table_walk(struct gmap *gmap, + unsigned long gaddr, int level) + { ++ const int asce_type = gmap->asce & _ASCE_TYPE_MASK; + unsigned long *table; + + if ((gmap->asce & _ASCE_TYPE_MASK) + 4 < (level * 4)) + return NULL; + if (gmap_is_shadow(gmap) && gmap->removed) + return NULL; +- if (gaddr & (-1UL << (31 + ((gmap->asce & _ASCE_TYPE_MASK) >> 2)*11))) ++ ++ if (asce_type != _ASCE_TYPE_REGION1 && ++ gaddr & (-1UL << (31 + (asce_type >> 2) * 11))) + return NULL; ++ + table = gmap->table; + switch (gmap->asce & _ASCE_TYPE_MASK) { + case _ASCE_TYPE_REGION1: diff --git a/queue-4.9/kvm-vmx-always-vmclear-in-use-vmcses-during-crash-with-kexec-support.patch b/queue-4.9/kvm-vmx-always-vmclear-in-use-vmcses-during-crash-with-kexec-support.patch new file mode 100644 index 00000000000..19da4fbdc14 --- /dev/null +++ b/queue-4.9/kvm-vmx-always-vmclear-in-use-vmcses-during-crash-with-kexec-support.patch @@ -0,0 +1,180 @@ +From 31603d4fc2bb4f0815245d496cb970b27b4f636a Mon Sep 17 00:00:00 2001 +From: Sean Christopherson +Date: Sat, 21 Mar 2020 12:37:49 -0700 +Subject: KVM: VMX: Always VMCLEAR in-use VMCSes during crash with kexec support + +From: Sean Christopherson + +commit 31603d4fc2bb4f0815245d496cb970b27b4f636a upstream. + +VMCLEAR all in-use VMCSes during a crash, even if kdump's NMI shootdown +interrupted a KVM update of the percpu in-use VMCS list. + +Because NMIs are not blocked by disabling IRQs, it's possible that +crash_vmclear_local_loaded_vmcss() could be called while the percpu list +of VMCSes is being modified, e.g. in the middle of list_add() in +vmx_vcpu_load_vmcs(). This potential corner case was called out in the +original commit[*], but the analysis of its impact was wrong. + +Skipping the VMCLEARs is wrong because it all but guarantees that a +loaded, and therefore cached, VMCS will live across kexec and corrupt +memory in the new kernel. Corruption will occur because the CPU's VMCS +cache is non-coherent, i.e. not snooped, and so the writeback of VMCS +memory on its eviction will overwrite random memory in the new kernel. +The VMCS will live because the NMI shootdown also disables VMX, i.e. the +in-progress VMCLEAR will #UD, and existing Intel CPUs do not flush the +VMCS cache on VMXOFF. + +Furthermore, interrupting list_add() and list_del() is safe due to +crash_vmclear_local_loaded_vmcss() using forward iteration. list_add() +ensures the new entry is not visible to forward iteration unless the +entire add completes, via WRITE_ONCE(prev->next, new). A bad "prev" +pointer could be observed if the NMI shootdown interrupted list_del() or +list_add(), but list_for_each_entry() does not consume ->prev. + +In addition to removing the temporary disabling of VMCLEAR, open code +loaded_vmcs_init() in __loaded_vmcs_clear() and reorder VMCLEAR so that +the VMCS is deleted from the list only after it's been VMCLEAR'd. +Deleting the VMCS before VMCLEAR would allow a race where the NMI +shootdown could arrive between list_del() and vmcs_clear() and thus +neither flow would execute a successful VMCLEAR. Alternatively, more +code could be moved into loaded_vmcs_init(), but that gets rather silly +as the only other user, alloc_loaded_vmcs(), doesn't need the smp_wmb() +and would need to work around the list_del(). + +Update the smp_*() comments related to the list manipulation, and +opportunistically reword them to improve clarity. + +[*] https://patchwork.kernel.org/patch/1675731/#3720461 + +Fixes: 8f536b7697a0 ("KVM: VMX: provide the vmclear function and a bitmap to support VMCLEAR in kdump") +Cc: stable@vger.kernel.org +Signed-off-by: Sean Christopherson +Message-Id: <20200321193751.24985-2-sean.j.christopherson@intel.com> +Reviewed-by: Vitaly Kuznetsov +Signed-off-by: Paolo Bonzini +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/kvm/vmx.c | 67 ++++++++++++----------------------------------------- + 1 file changed, 16 insertions(+), 51 deletions(-) + +--- a/arch/x86/kvm/vmx.c ++++ b/arch/x86/kvm/vmx.c +@@ -1619,43 +1619,15 @@ static void vmcs_load(struct vmcs *vmcs) + } + + #ifdef CONFIG_KEXEC_CORE +-/* +- * This bitmap is used to indicate whether the vmclear +- * operation is enabled on all cpus. All disabled by +- * default. +- */ +-static cpumask_t crash_vmclear_enabled_bitmap = CPU_MASK_NONE; +- +-static inline void crash_enable_local_vmclear(int cpu) +-{ +- cpumask_set_cpu(cpu, &crash_vmclear_enabled_bitmap); +-} +- +-static inline void crash_disable_local_vmclear(int cpu) +-{ +- cpumask_clear_cpu(cpu, &crash_vmclear_enabled_bitmap); +-} +- +-static inline int crash_local_vmclear_enabled(int cpu) +-{ +- return cpumask_test_cpu(cpu, &crash_vmclear_enabled_bitmap); +-} +- + static void crash_vmclear_local_loaded_vmcss(void) + { + int cpu = raw_smp_processor_id(); + struct loaded_vmcs *v; + +- if (!crash_local_vmclear_enabled(cpu)) +- return; +- + list_for_each_entry(v, &per_cpu(loaded_vmcss_on_cpu, cpu), + loaded_vmcss_on_cpu_link) + vmcs_clear(v->vmcs); + } +-#else +-static inline void crash_enable_local_vmclear(int cpu) { } +-static inline void crash_disable_local_vmclear(int cpu) { } + #endif /* CONFIG_KEXEC_CORE */ + + static void __loaded_vmcs_clear(void *arg) +@@ -1667,19 +1639,24 @@ static void __loaded_vmcs_clear(void *ar + return; /* vcpu migration can race with cpu offline */ + if (per_cpu(current_vmcs, cpu) == loaded_vmcs->vmcs) + per_cpu(current_vmcs, cpu) = NULL; +- crash_disable_local_vmclear(cpu); ++ ++ vmcs_clear(loaded_vmcs->vmcs); ++ if (loaded_vmcs->shadow_vmcs && loaded_vmcs->launched) ++ vmcs_clear(loaded_vmcs->shadow_vmcs); ++ + list_del(&loaded_vmcs->loaded_vmcss_on_cpu_link); + + /* +- * we should ensure updating loaded_vmcs->loaded_vmcss_on_cpu_link +- * is before setting loaded_vmcs->vcpu to -1 which is done in +- * loaded_vmcs_init. Otherwise, other cpu can see vcpu = -1 fist +- * then adds the vmcs into percpu list before it is deleted. ++ * Ensure all writes to loaded_vmcs, including deleting it from its ++ * current percpu list, complete before setting loaded_vmcs->vcpu to ++ * -1, otherwise a different cpu can see vcpu == -1 first and add ++ * loaded_vmcs to its percpu list before it's deleted from this cpu's ++ * list. Pairs with the smp_rmb() in vmx_vcpu_load_vmcs(). + */ + smp_wmb(); + +- loaded_vmcs_init(loaded_vmcs); +- crash_enable_local_vmclear(cpu); ++ loaded_vmcs->cpu = -1; ++ loaded_vmcs->launched = 0; + } + + static void loaded_vmcs_clear(struct loaded_vmcs *loaded_vmcs) +@@ -2471,18 +2448,17 @@ static void vmx_vcpu_load(struct kvm_vcp + + if (!already_loaded) { + local_irq_disable(); +- crash_disable_local_vmclear(cpu); + + /* +- * Read loaded_vmcs->cpu should be before fetching +- * loaded_vmcs->loaded_vmcss_on_cpu_link. +- * See the comments in __loaded_vmcs_clear(). ++ * Ensure loaded_vmcs->cpu is read before adding loaded_vmcs to ++ * this cpu's percpu list, otherwise it may not yet be deleted ++ * from its previous cpu's percpu list. Pairs with the ++ * smb_wmb() in __loaded_vmcs_clear(). + */ + smp_rmb(); + + list_add(&vmx->loaded_vmcs->loaded_vmcss_on_cpu_link, + &per_cpu(loaded_vmcss_on_cpu, cpu)); +- crash_enable_local_vmclear(cpu); + local_irq_enable(); + } + +@@ -3510,17 +3486,6 @@ static int hardware_enable(void) + INIT_LIST_HEAD(&per_cpu(blocked_vcpu_on_cpu, cpu)); + spin_lock_init(&per_cpu(blocked_vcpu_on_cpu_lock, cpu)); + +- /* +- * Now we can enable the vmclear operation in kdump +- * since the loaded_vmcss_on_cpu list on this cpu +- * has been initialized. +- * +- * Though the cpu is not in VMX operation now, there +- * is no problem to enable the vmclear operation +- * for the loaded_vmcss_on_cpu list is empty! +- */ +- crash_enable_local_vmclear(cpu); +- + rdmsrl(MSR_IA32_FEATURE_CONTROL, old); + + test_bits = FEATURE_CONTROL_LOCKED; diff --git a/queue-4.9/kvm-vmx-fix-crash-cleanup-when-kvm-wasn-t-used.patch b/queue-4.9/kvm-vmx-fix-crash-cleanup-when-kvm-wasn-t-used.patch new file mode 100644 index 00000000000..d3658fd5b47 --- /dev/null +++ b/queue-4.9/kvm-vmx-fix-crash-cleanup-when-kvm-wasn-t-used.patch @@ -0,0 +1,75 @@ +From dbef2808af6c594922fe32833b30f55f35e9da6d Mon Sep 17 00:00:00 2001 +From: Vitaly Kuznetsov +Date: Wed, 1 Apr 2020 10:13:48 +0200 +Subject: KVM: VMX: fix crash cleanup when KVM wasn't used + +From: Vitaly Kuznetsov + +commit dbef2808af6c594922fe32833b30f55f35e9da6d upstream. + +If KVM wasn't used at all before we crash the cleanup procedure fails with + BUG: unable to handle page fault for address: ffffffffffffffc8 + #PF: supervisor read access in kernel mode + #PF: error_code(0x0000) - not-present page + PGD 23215067 P4D 23215067 PUD 23217067 PMD 0 + Oops: 0000 [#8] SMP PTI + CPU: 0 PID: 3542 Comm: bash Kdump: loaded Tainted: G D 5.6.0-rc2+ #823 + RIP: 0010:crash_vmclear_local_loaded_vmcss.cold+0x19/0x51 [kvm_intel] + +The root cause is that loaded_vmcss_on_cpu list is not yet initialized, +we initialize it in hardware_enable() but this only happens when we start +a VM. + +Previously, we used to have a bitmap with enabled CPUs and that was +preventing [masking] the issue. + +Initialized loaded_vmcss_on_cpu list earlier, right before we assign +crash_vmclear_loaded_vmcss pointer. blocked_vcpu_on_cpu list and +blocked_vcpu_on_cpu_lock are moved altogether for consistency. + +Fixes: 31603d4fc2bb ("KVM: VMX: Always VMCLEAR in-use VMCSes during crash with kexec support") +Signed-off-by: Vitaly Kuznetsov +Message-Id: <20200401081348.1345307-1-vkuznets@redhat.com> +Reviewed-by: Sean Christopherson +Signed-off-by: Paolo Bonzini +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/kvm/vmx.c | 12 +++++++----- + 1 file changed, 7 insertions(+), 5 deletions(-) + +--- a/arch/x86/kvm/vmx.c ++++ b/arch/x86/kvm/vmx.c +@@ -3482,10 +3482,6 @@ static int hardware_enable(void) + if (cr4_read_shadow() & X86_CR4_VMXE) + return -EBUSY; + +- INIT_LIST_HEAD(&per_cpu(loaded_vmcss_on_cpu, cpu)); +- INIT_LIST_HEAD(&per_cpu(blocked_vcpu_on_cpu, cpu)); +- spin_lock_init(&per_cpu(blocked_vcpu_on_cpu_lock, cpu)); +- + rdmsrl(MSR_IA32_FEATURE_CONTROL, old); + + test_bits = FEATURE_CONTROL_LOCKED; +@@ -11860,7 +11856,7 @@ module_exit(vmx_exit) + + static int __init vmx_init(void) + { +- int r; ++ int r, cpu; + + r = kvm_init(&vmx_x86_ops, sizeof(struct vcpu_vmx), + __alignof__(struct vcpu_vmx), THIS_MODULE); +@@ -11882,6 +11878,12 @@ static int __init vmx_init(void) + } + } + ++ for_each_possible_cpu(cpu) { ++ INIT_LIST_HEAD(&per_cpu(loaded_vmcss_on_cpu, cpu)); ++ INIT_LIST_HEAD(&per_cpu(blocked_vcpu_on_cpu, cpu)); ++ spin_lock_init(&per_cpu(blocked_vcpu_on_cpu_lock, cpu)); ++ } ++ + #ifdef CONFIG_KEXEC_CORE + rcu_assign_pointer(crash_vmclear_loaded_vmcss, + crash_vmclear_local_loaded_vmcss); diff --git a/queue-4.9/kvm-x86-allocate-new-rmap-and-large-page-tracking-when-moving-memslot.patch b/queue-4.9/kvm-x86-allocate-new-rmap-and-large-page-tracking-when-moving-memslot.patch new file mode 100644 index 00000000000..2a790a02468 --- /dev/null +++ b/queue-4.9/kvm-x86-allocate-new-rmap-and-large-page-tracking-when-moving-memslot.patch @@ -0,0 +1,102 @@ +From edd4fa37baa6ee8e44dc65523b27bd6fe44c94de Mon Sep 17 00:00:00 2001 +From: Sean Christopherson +Date: Tue, 18 Feb 2020 13:07:15 -0800 +Subject: KVM: x86: Allocate new rmap and large page tracking when moving memslot + +From: Sean Christopherson + +commit edd4fa37baa6ee8e44dc65523b27bd6fe44c94de upstream. + +Reallocate a rmap array and recalcuate large page compatibility when +moving an existing memslot to correctly handle the alignment properties +of the new memslot. The number of rmap entries required at each level +is dependent on the alignment of the memslot's base gfn with respect to +that level, e.g. moving a large-page aligned memslot so that it becomes +unaligned will increase the number of rmap entries needed at the now +unaligned level. + +Not updating the rmap array is the most obvious bug, as KVM accesses +garbage data beyond the end of the rmap. KVM interprets the bad data as +pointers, leading to non-canonical #GPs, unexpected #PFs, etc... + + general protection fault: 0000 [#1] SMP + CPU: 0 PID: 1909 Comm: move_memory_reg Not tainted 5.4.0-rc7+ #139 + Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 + RIP: 0010:rmap_get_first+0x37/0x50 [kvm] + Code: <48> 8b 3b 48 85 ff 74 ec e8 6c f4 ff ff 85 c0 74 e3 48 89 d8 5b c3 + RSP: 0018:ffffc9000021bbc8 EFLAGS: 00010246 + RAX: ffff00617461642e RBX: ffff00617461642e RCX: 0000000000000012 + RDX: ffff88827400f568 RSI: ffffc9000021bbe0 RDI: ffff88827400f570 + RBP: 0010000000000000 R08: ffffc9000021bd00 R09: ffffc9000021bda8 + R10: ffffc9000021bc48 R11: 0000000000000000 R12: 0030000000000000 + R13: 0000000000000000 R14: ffff88827427d700 R15: ffffc9000021bce8 + FS: 00007f7eda014700(0000) GS:ffff888277a00000(0000) knlGS:0000000000000000 + CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 + CR2: 00007f7ed9216ff8 CR3: 0000000274391003 CR4: 0000000000162eb0 + Call Trace: + kvm_mmu_slot_set_dirty+0xa1/0x150 [kvm] + __kvm_set_memory_region.part.64+0x559/0x960 [kvm] + kvm_set_memory_region+0x45/0x60 [kvm] + kvm_vm_ioctl+0x30f/0x920 [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:0x7f7ed9911f47 + Code: <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 21 6f 2c 00 f7 d8 64 89 01 48 + RSP: 002b:00007ffc00937498 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 + RAX: ffffffffffffffda RBX: 0000000001ab0010 RCX: 00007f7ed9911f47 + RDX: 0000000001ab1350 RSI: 000000004020ae46 RDI: 0000000000000004 + RBP: 000000000000000a R08: 0000000000000000 R09: 00007f7ed9214700 + R10: 00007f7ed92149d0 R11: 0000000000000246 R12: 00000000bffff000 + R13: 0000000000000003 R14: 00007f7ed9215000 R15: 0000000000000000 + Modules linked in: kvm_intel kvm irqbypass + ---[ end trace 0c5f570b3358ca89 ]--- + +The disallow_lpage tracking is more subtle. Failure to update results +in KVM creating large pages when it shouldn't, either due to stale data +or again due to indexing beyond the end of the metadata arrays, which +can lead to memory corruption and/or leaking data to guest/userspace. + +Note, the arrays for the old memslot are freed by the unconditional call +to kvm_free_memslot() in __kvm_set_memory_region(). + +Fixes: 05da45583de9b ("KVM: MMU: large page support") +Cc: stable@vger.kernel.org +Signed-off-by: Sean Christopherson +Reviewed-by: Peter Xu +Signed-off-by: Paolo Bonzini +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/kvm/x86.c | 11 +++++++++++ + 1 file changed, 11 insertions(+) + +--- a/arch/x86/kvm/x86.c ++++ b/arch/x86/kvm/x86.c +@@ -8319,6 +8319,13 @@ int kvm_arch_create_memslot(struct kvm * + { + int i; + ++ /* ++ * Clear out the previous array pointers for the KVM_MR_MOVE case. The ++ * old arrays will be freed by __kvm_set_memory_region() if installing ++ * the new memslot is successful. ++ */ ++ memset(&slot->arch, 0, sizeof(slot->arch)); ++ + for (i = 0; i < KVM_NR_PAGE_SIZES; ++i) { + struct kvm_lpage_info *linfo; + unsigned long ugfn; +@@ -8392,6 +8399,10 @@ int kvm_arch_prepare_memory_region(struc + const struct kvm_userspace_memory_region *mem, + enum kvm_mr_change change) + { ++ if (change == KVM_MR_MOVE) ++ return kvm_arch_create_memslot(kvm, memslot, ++ mem->memory_size >> PAGE_SHIFT); ++ + return 0; + } + diff --git a/queue-4.9/series b/queue-4.9/series index c5d0659daea..f34ac306af2 100644 --- a/queue-4.9/series +++ b/queue-4.9/series @@ -32,3 +32,10 @@ mips-octeon-irq-fix-potential-null-pointer-dereference.patch ath9k-handle-txpower-changes-even-when-tpc-is-disabled.patch signal-extend-exec_id-to-64bits.patch x86-entry-32-add-missing-asm_clac-to-general_protection-entry.patch +kvm-s390-vsie-fix-region-1-asce-sanity-shadow-address-checks.patch +kvm-s390-vsie-fix-delivery-of-addressing-exceptions.patch +kvm-x86-allocate-new-rmap-and-large-page-tracking-when-moving-memslot.patch +kvm-vmx-always-vmclear-in-use-vmcses-during-crash-with-kexec-support.patch +kvm-vmx-fix-crash-cleanup-when-kvm-wasn-t-used.patch +btrfs-drop-block-from-cache-on-error-in-relocation.patch +crypto-mxs-dcp-fix-scatterlist-linearization-for-hash.patch