Permission checks on the emulation paths (intended for guests using nested virtualization) for VMLAUNCH and VMRESUME were deferred too much. The hypervisor would try to use internal state which is not set up unless nested virtualization is actually enabled for a guest. A malicious or misbehaved HVM guest, including malicious or misbehaved user mode code run in the guest, might be able to crash the host. Xen 4.2.x and later are vulnerable. Xen 4.1.x and earlier are not vulnerable. Only HVM guests run on VMX capable (e.g. Intel) hardware can take advantage of this vulnerability. Running only PV guests, or running HVM guests on SVM capable (e.g. AMD) hardware will avoid this issue. Enabling nested virtualization for a HVM guest running on VMX capable hardware would also allow avoiding the issue. However this functionality is still considered experimental, and is not covered by security support from the Xen Project security team. This approach is therefore not recommended for use in production.
Statement: Not vulnerable. This issue did not affect the versions of the kernel-xen package as shipped with Red Hat Enterprise Linux 5. This issue did not affect the versions of the Linux kernel as shipped with Red Hat Enterprise Linux 6 and Red Hat Enterprise MRG as we did not have support for Xen hypervisor.
Created xen tracking bugs for this issue: Affects: fedora-all [bug 1029055]