A buggy loop in Xen's compat_iret() function iterates the wrong way around a 32-bit index. Any 32-bit PV guest kernel can trigger this vulnerability by attempting a hypercall_iret with EFLAGS.VM set.
Given the use of __get/put_user(), and that the virtual addresses in question are contained within the lower canonical half, the guest cannot clobber any hypervisor data. Instead, Xen will take up to 2^33 pagefaults, in sequence, effectively hanging the host.
Malicious guest administrators can cause a denial of service affecting the whole system.
Only 64-bit x86 (ARCH=x86_64) builds of Xen are vulnerable. 32-bit builds (ARCH=x86_32) (necessarily of Xen 4.2 or earlier), are not affected.
Xen versions 3.1 or later are vulnerable.
ARM systems are not vulnerable.
Only 32-bit PV guests can exploit the vulnerability.
Systems which only need to run 32-bit guests and are running Xen 4.2 or earlier can avoid the vulnerability by using a 32-bit build of Xen instead of a 64-bit build. (The dom0 operating system would have to be 32-bit too.)
If the boot process and kernel for the guest can be controlled, forcing it to use a 64-bit kernel will avoid the vulnerability.
Red Hat would like to thank the Xen project for reporting this issue.
This issue does affect the Xen hypervisor packages as shipped with Red Hat Enterprise Linux 5.
Red Hat Enterprise Linux 5 is now in Production 3 Phase of the support and maintenance life cycle. This has been rated as having Moderate security impact and is not currently planned to be addressed in future updates. For additional information, refer to the Red Hat Enterprise Linux Life Cycle: https://access.redhat.com/support/policy/updates/errata/.