Given the complexity of QEMU and its pace of development, there is likely an endless supply of such bugs for punching through the QEMU emulation layer. The problem is that most of the time, the QEMU process is running in dom0, giving an attacker an opportunity to hijack the hypervisor. Xen offers a more general solution for this: running QEMU in a stub domain. The main problem with that solution right now is that Xen forked QEMU such that the stub domain only supports running QEMU 0.10 or such - the up-to-date version of QEMU (known in Xen as qemu-upstream) is somewhere around 2.2, but it runs the emulation layer as a process in dom0, which exposes the system as a whole to "VENOM" and related attacks on QEMU.