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.