kernel virtual machine

This applies to kvm-84 and earlier (and possibly to the in-kernel kvm
version too) on all x86 machines in all guest modes (32-bit, PAE, 64-bit).

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.

The result is extraordinarily disruptive: the kernel correctly catches the
NULL pointer, but kvm is holding numerous kernel-wide locks by that point.
This means the calling process (e.g. QEMU) can't be killed, any other
process that accesses parts of sysfs or the filesystem will hang, and in
some cases sync() itself hangs before attempting to cleanly reboot,
resulting in data loss.

This becomes an EXPLOITABLE bug when non-root users can create or
manipulate KVM VMs (i.e. /dev/kvm is g+rw, which is the default in many
distros now), and QEMU or another tool is modified to pass corrupted cr3
values to kvm.

Two other remotely exploitable attack vectors are also possible:

- cr3 can be corrupted in a QEMU snapshot on disk, which will trigger the
bug when the snapshot is restored.

- cr3 can be corrupted during migration or network transfer, resulting in
the migration target host system hanging.

Fortunately, it doesn't appear this bug can be exploited for privilege
escalation, but it's clearly a possible DoS attack vector. It could also be
used to trigger data loss on the host if the attacker ensures a malicious
QEMU process is holding locks on certain files and/or sysfs entries at the
time the attack is attemped (either explicitly or via race conditions).

I've attached a patch that adds cr3 validation to mmu_alloc_roots(), so
vcpu_enter_guest() will simply return -EFAULT to userspace if it tries to
activate a cr3 value pointing to an inaccessible guest physical page. In
addition, the patch prints a syslog warning like "mmu_alloc_roots(vcpu 0):
caller attempted to load a bogus root_gfn xxxxxx".