summaryrefslogtreecommitdiff
path: root/arch
diff options
context:
space:
mode:
authorAlexis Dambricourt <alexis.dambricourt@gmail.com>2016-07-04 21:05:15 +0200
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>2016-08-20 18:09:17 +0200
commitb9ab0b3614fca6b363b2f2cfa918e7b7f74592ea (patch)
tree27b2b859056f2665580783243371112c2a81130e /arch
parent41490064ad279e8364d993e0cb1117209799fd80 (diff)
KVM: MTRR: fix kvm_mtrr_check_gfn_range_consistency page fault
commit 30b072ce0356e8b141f4ca6da7220486fa3641d9 upstream. The following #PF may occurs: [ 1403.317041] BUG: unable to handle kernel paging request at 0000000200000068 [ 1403.317045] IP: [<ffffffffc04c20b0>] __mtrr_lookup_var_next+0x10/0xa0 [kvm] [ 1403.317123] Call Trace: [ 1403.317134] [<ffffffffc04c2a65>] ? kvm_mtrr_check_gfn_range_consistency+0xc5/0x120 [kvm] [ 1403.317143] [<ffffffffc04ac11f>] ? tdp_page_fault+0x9f/0x2c0 [kvm] [ 1403.317152] [<ffffffffc0498128>] ? kvm_set_msr_common+0x858/0xc00 [kvm] [ 1403.317161] [<ffffffffc04b8883>] ? x86_emulate_insn+0x273/0xd30 [kvm] [ 1403.317171] [<ffffffffc04c04e4>] ? kvm_cpuid+0x34/0x190 [kvm] [ 1403.317180] [<ffffffffc04a5bb9>] ? kvm_mmu_page_fault+0x59/0xe0 [kvm] [ 1403.317183] [<ffffffffc0d729e1>] ? vmx_handle_exit+0x1d1/0x14a0 [kvm_intel] [ 1403.317185] [<ffffffffc0d75f3f>] ? atomic_switch_perf_msrs+0x6f/0xa0 [kvm_intel] [ 1403.317187] [<ffffffffc0d7621d>] ? vmx_vcpu_run+0x2ad/0x420 [kvm_intel] [ 1403.317196] [<ffffffffc04a0962>] ? kvm_arch_vcpu_ioctl_run+0x622/0x1550 [kvm] [ 1403.317204] [<ffffffffc049abb9>] ? kvm_arch_vcpu_load+0x59/0x210 [kvm] [ 1403.317206] [<ffffffff81036245>] ? __kernel_fpu_end+0x35/0x100 [ 1403.317213] [<ffffffffc0487eb6>] ? kvm_vcpu_ioctl+0x316/0x5d0 [kvm] [ 1403.317215] [<ffffffff81088225>] ? do_sigtimedwait+0xd5/0x220 [ 1403.317217] [<ffffffff811f84dd>] ? do_vfs_ioctl+0x9d/0x5c0 [ 1403.317224] [<ffffffffc04928ae>] ? kvm_on_user_return+0x3e/0x70 [kvm] [ 1403.317225] [<ffffffff811f8a74>] ? SyS_ioctl+0x74/0x80 [ 1403.317227] [<ffffffff815bf0b6>] ? entry_SYSCALL_64_fastpath+0x1e/0xa8 [ 1403.317242] RIP [<ffffffffc04c20b0>] __mtrr_lookup_var_next+0x10/0xa0 [kvm] At mtrr_lookup_fixed_next(), when the condition 'if (iter->index >= ARRAY_SIZE(iter->mtrr_state->fixed_ranges))' becomes true, mtrr_lookup_var_start() is called with iter->range with gargabe values from the fixed MTRR union field. Then, list_prepare_entry() do not call list_entry() initialization, keeping a garbage pointer in iter->range which is accessed in the following __mtrr_lookup_var_next() call. Fixes: f571c0973e4b8c888e049b6842e4b4f93b5c609c Signed-off-by: Alexis Dambricourt <alexis@blade-group.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Diffstat (limited to 'arch')
-rw-r--r--arch/x86/kvm/mtrr.c1
1 files changed, 1 insertions, 0 deletions
diff --git a/arch/x86/kvm/mtrr.c b/arch/x86/kvm/mtrr.c
index c146f3c262c3..0149ac59c273 100644
--- a/arch/x86/kvm/mtrr.c
+++ b/arch/x86/kvm/mtrr.c
@@ -539,6 +539,7 @@ static void mtrr_lookup_var_start(struct mtrr_iter *iter)
iter->fixed = false;
iter->start_max = iter->start;
+ iter->range = NULL;
iter->range = list_prepare_entry(iter->range, &mtrr_state->head, node);
__mtrr_lookup_var_next(iter);