several HVM operations do not validate the range of their inputs
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.
lack of check (invalid input)
hvm: Limit the size of large HVM op batches
Doing large p2m updates for HVMOP_track_dirty_vram without preemption ties up the physical processor. Integrating preemption into the p2m updates is hard so simply limit to 1GB which is sufficient for a 15000 * 15000 * 32bpp framebuffer.
For HVMOP_modified_memory and HVMOP_set_mem_type preemptible add the necessary machinery to handle preemption.
A malicious guest administrator can cause Xen to become unresponsive or to crash leading in either case to a Denial of Service.