Several HVM control operations do not check the size of their inputs and can tie up a physical CPU for extended periods of time. In addition dirty video RAM tracking involves clearing the bitmap provided by the domain controlling the guest (e.g. dom0 or a stubdom). If the size of that bitmap is overly large, an intermediate variable on the hypervisor stack may overflow that stack. A malicious guest administrator can cause Xen to become unresponsive or to crash leading in either case to a Denial of Service. Acknowledgements: Red Hat would like to thank the Xen project for reporting this issue.
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 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 883084]
xen-4.2.0-6.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.
xen-4.1.3-7.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report.
*** Bug 886863 has been marked as a duplicate of this bug. ***
xen-4.1.3-6.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report.