When constructing a guest which is configured to use a PV bootloader which runs as a userspace process in the toolstack domain (e.g. pygrub) libxl creates a mapping of the files to be used as kernel and initial ramdisk when building the guest domain. However if building the domain subsequently fails these mappings would not be released leading to a leak of virtual address space in the calling process, as well as preventing the recovery of the temporary disk files containing the kernel and initial ramdisk.
For toolstacks which manage multiple domains within the same process, an attacker who is able to repeatedly start a suitable domain (or many such domains) can cause an out-of-memory condition in the toolstack process, leading to a denial of service. Under the same circumstances an attacker can also cause files to accumulate on the toolstack domain filesystem (usually under /var in dom0) used to temporarily store the kernel and initial ramdisk, perhaps leading to a denial of service against arbitrary other services using that filesystem.
Both ARM and x86 systems using a libxl based toolstack are potentially vulnerable.
Only libxl-based toolstacks which manage multiple domains in the same process (such as
libvirt') are vulnerable.
libxl-based toolstacks which manage only a single domain per process and which exit on failure to create a domain (such asxl') are not vulnerable.
Toolstacks not using libxl are not vulnerable to this issue.
Only domains configured to use a PV bootloader in the toolstack domain (e.g. pygrub) will expose this issue. Domains configured to use pvgrub (a totally different program) are not vulnerable.
x86 HVM domains are not vulnerable.
Systems where the kernel and initial ramdisk are provided by the host administrator from files in domain 0 are not vulnerable.
Xen versions 4.1.x and later are vulnerable.