Unsanitised guest input in libxl device handling code

ISSUE DESCRIPTION

Various parts of libxl device-handling code inappropriately use information from (partially) guest controlled areas of xenstore (principally the frontend directory /local/domain/GUEST/device/TYPE/DEVID, henceforth referred to as FE). The problems vary by device type:
For almost all device types (all devices except consoles and channels), the guest has the ability to completely remove FE. This will normally result in the virtual device no longer functioning (which is bad for the guest and an outcome the guest could achieve anyway). But it will also cause the device not to appear in lists of devices, and prevent the device being properly torn down during domain destruction (including guest reboot and migration). When such a malicious domain is shut down, the host resources associated with the manipulated devices may remain in use: for example, disk and nic hotplug teardown scripts will not be run. For resources allocated in an manner which excludes some other accesses, this can prevent the operation of that other software on the host (for example, it can prevent management operations on the underlying objects); for resources are allocated in a nonexclusive manner, the guest can consume new resources with each successive guest boot, eventually exhausting capacity.
For all devices other than the main PV console, the guest can write FE/backend to point to the backend of a device belonging to a different guest. On subsequent domain removal (for example, by guest reboot or migration) libxl uses this value with insufficient checks, allowing libxl to be tricked into failing to tear down the device properly.
For almost all device types the backend xenstore path and domid returned to libxl’s caller during query functions servicing the domain are read from a guest-controlled part of xenstore. This means that a guest can cause incorrect displays in tools like xl, and possibly cause maloperation by higher-level domain management systems.
For all device types, libxl would read the guest-writeable FE/backend node to find the xenstore path to the backend. A guest could write a bad value, which would (mostly) be detected by libxl but would cause libxl operations (including informational functions) to fail.
For consoles, vtpm and channel devices, libxl would use FE/backend without checking, to discover important information about the device. For vtpm devices, this means guest can manipulate the apparently-configured uuid. For channel devices, the guest can manipulate the apparently-configured channel name.
For channel devices, the guest can trick console attachment tools in the backend domain into connecting to arbitrary wrong paths on the backend domain filesystem.

IMPACT

A malicious guest administrator can cause denial of service by resource exhaustion.
A malicious guest administrator can confuse and/or deny service to management facilities.
A malicious guest administrator of a guest configured with channel devices may be able to escalate their privilege to that of the backend domain (i.e., normally, to that of the host).

VULNERABLE SYSTEMS

Xen systems using libxl based toolstacks (for example xl or libvirt with the libxl driver) are vulnerable to denial of service to guests and administrators.
Xen systems with guests configured with channel devices are possibly vulnerable to privilege escalation by those guests.
(Channel devices are be configured with “channel=” in the xl domain configuration file. See <a href=“http://xenbits.xen.org/docs/4.6-testing/misc/channel.txt”>http://xenbits.xen.org/docs/4.6-testing/misc/channel.txt</a> for more information.)