Re: [PATCH] KVM: MTRR: fix kvm_mtrr_check_gfn_range_consistency page fault

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On 04/07/2016 21:05, Alexis Dambricourt wrote:
> 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.
> 
> Signed-off-by: Alexis Dambricourt <alexis@xxxxxxxxxxxxxxx>
> ---
>  arch/x86/kvm/mtrr.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/x86/kvm/mtrr.c b/arch/x86/kvm/mtrr.c
> index c146f3c..0149ac5 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);
> 

Thanks, looks good.

Paolo
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux