Xen Security Advisory XSA-175
Unsanitised guest input in libxl device handling code
*** EMBARGOED UNTIL 2016-06-02 12:00 UTC ***
UPDATES IN VERSION 2
Include draft of backports to 4.6. These have been run through a
private instance of osstest, but please test them and report issues as
soon as possible.
NB that vusb was introduced in 4.7, so the vusb-related patch has not
been backported to 4.6.
Various parts of libxl device-handling code inappropriately use
information from (partially) guest controlled areas of xenstore
(principally the frontend directory
henceforth referred to as FE). The problems vary by device type:
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 tearing down devices belonging to
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
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.
A malicious guest administrator can cause denial of service to other
A malicious guest administrator can confuse and/or deny service to
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).
Xen systems using libxl based toolstacks (for example xl or libvirt
with the libxl driver) are vulnerable to denial of service to guests
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
for more information.)
Disabling channel devices in applicable guests will reduce the
impact of the vulnerability.
Limiting the frequency with which a guest is able to reboot, or
limiting or eliminating a guest's ability to be granted exclusive
access to host resources, will reduce the resource exhaustion impact.
Applying the appropriate attached patch resolves this issue.
$ sha256sum xsa175-*/*
Files forwarded to Maintainer in an encrypted channel.
Author: Yixun Lan <email@example.com>
Date: Tue Jun 7 13:38:13 2016 +0800
app-emulation/xen-tools: fix XSA-175,178 bug
also include a few non-security upstream fixes
Gentoo-Bug: 583464, XSA-175
Gentoo-Bug: 583466, XSA-178
@ Security: Please vote!
The libxl device-handling in Xen 4.6.x and earlier allows local OS guest
administrators to cause a denial of service (resource consumption or
management facility confusion) or gain host OS privileges by manipulating
information in guest controlled areas of xenstore.
GLSA Vote: No