From: Avi Kivity <avi@redhat.com>
To: Marcelo Tosatti <mtosatti@redhat.com>
Cc: kvm <kvm@vger.kernel.org>
Subject: Re: KVM: x86: check for cr3 validity in ioctl_set_sregs
Date: Thu, 16 Apr 2009 15:49:24 +0300 [thread overview]
Message-ID: <49E72954.8040005@redhat.com> (raw)
In-Reply-To: <49E727D3.8050306@redhat.com>
Avi Kivity wrote:
> Marcelo Tosatti wrote:
>> Matt T. Yourst notes that kvm_arch_vcpu_ioctl_set_sregs lacks validity
>> checking for the new cr3 value:
>> "Userspace callers of KVM_SET_SREGS can pass a bogus value of
>> cr3 to
>> the kernel. This will trigger a NULL pointer access in gfn_to_rmap()
>> when userspace next tries to call KVM_RUN on the affected VCPU and kvm
>> attempts to activate the new non-existent page table root.
>>
>> This happens since kvm only validates that cr3 points to a valid guest
>> physical memory page when code *inside* the guest sets cr3. However, kvm
>> currently trusts the userspace caller (e.g. QEMU) on the host machine to
>> always supply a valid page table root, rather than properly validating
>> it along with the rest of the reloaded guest state."
>>
>> http://sourceforge.net/tracker/?func=detail&atid=893831&aid=2687641&group_id=180599
>>
>>
>> Check for a valid cr3 address in kvm_arch_vcpu_ioctl_set_sregs, triple
>> fault in case of failure.
>>
>> Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
>>
>> Index: kvm/arch/x86/kvm/x86.c
>> ===================================================================
>> --- kvm.orig/arch/x86/kvm/x86.c
>> +++ kvm/arch/x86/kvm/x86.c
>> @@ -3986,7 +3986,13 @@ int kvm_arch_vcpu_ioctl_set_sregs(struct
>>
>> vcpu->arch.cr2 = sregs->cr2;
>> mmu_reset_needed |= vcpu->arch.cr3 != sregs->cr3;
>> - vcpu->arch.cr3 = sregs->cr3;
>> +
>> + down_read(&vcpu->kvm->slots_lock);
>> + if (gfn_to_memslot(vcpu->kvm, sregs->cr3 >> PAGE_SHIFT))
>> + vcpu->arch.cr3 = sregs->cr3;
>> + else
>> + set_bit(KVM_REQ_TRIPLE_FAULT, &vcpu->requests);
>> + up_read(&vcpu->kvm->slots_lock);
>>
>> kvm_set_cr8(vcpu, sregs->cr8);
>>
>>
>
> Isn't this self-defeating? If you drop slots_lock, cr3 may be invalid
> again by the time you set cvpu->arch.cr3?
>
Uh, sorry, of course not. I misread down as up. Bad day for me. Will
apply the patch.
Still, don't we have a problem if userspace drops the memory slot where
cr3 points to?
--
Do not meddle in the internals of kernels, for they are subtle and quick to panic.
prev parent reply other threads:[~2009-04-16 12:49 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-15 22:10 KVM: x86: use kvm_set_cr3/cr4 in ioctl_set_sregs Marcelo Tosatti
2009-04-16 8:56 ` Avi Kivity
2009-04-16 9:10 ` Marcelo Tosatti
2009-04-16 9:23 ` Avi Kivity
2009-04-16 11:30 ` KVM: x86: check for cr3 validity " Marcelo Tosatti
2009-04-16 12:42 ` Avi Kivity
2009-04-16 12:49 ` Avi Kivity [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=49E72954.8040005@redhat.com \
--to=avi@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=mtosatti@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox