|Public release ||2015-12-08 11:29|
|Updated ||2015-12-08 11:29|
|Title ||libxl leak of pv kernel and initrd on error|
Filesadvisory-160.txt (signed advisory file)
-----BEGIN PGP SIGNED MESSAGE-----
Xen Security Advisory CVE-2015-8341 / XSA-160
libxl leak of pv kernel and initrd on error
UPDATES IN VERSION 3
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
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 as `xl') are not
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.
Avoiding the use of the PV bootloader mechanisms which run as
processes in the toolstack domain (pygrub), either by providing
kernels directly from the toolstack domain or using a PV bootloader
which runs in guest context (such as pvgrub) will prevent exposure of
This issue was discovered by George Dunlap of Citrix.
Applying the appropriate attached patch resolves this issue.
xsa160-4.6.patch Xen 4.5.x, 4.6.x
xsa160-4.4.patch Xen 4.3.x, 4.4.x
$ sha256sum xsa160*
DEPLOYMENT DURING EMBARGO
Deployment of the patch described above (or others which are
substantially similar) is permitted during the embargo, even on
public-facing systems with untrusted guest users and administrators.
However deployment of the mitigations described above is not permitted
(except where all the affected systems and VMs are administered and
used only by organisations which are members of the Xen Project
Security Issues Predisclosure List). Specifically, deployment on
public cloud systems is NOT permitted.
This is because such a change to the bootloader arrangements of a PV
guest would be a user-visible change which could lead to the
rediscovery of the vulnerability.
But: Distribution of updated software is prohibited (except to other
members of the predisclosure list).
Predisclosure list members who wish to deploy significantly different
patches and/or mitigations, please contact the Xen Project Security
(Note: this during-embargo deployment notice is retained in
post-embargo publicly released Xen Project advisories, even though it
is then no longer applicable. This is to enable the community to have
oversight of the Xen Project Security Team's decisionmaking.)
For more information about permissible uses of embargoed information,
consult the Xen Project community's agreed Security Policy:
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
-----END PGP SIGNATURE-----
Xenproject.org Security Team