-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

            Xen Security Advisory CVE-2015-8341 / XSA-160
                              version 3

              libxl leak of pv kernel and initrd on error

UPDATES IN VERSION 3
====================

Public release.

ISSUE DESCRIPTION
=================

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.

IMPACT
======

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.

VULNERABLE SYSTEMS
==================

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 as `xl') 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.

MITIGATION
==========

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.

CREDITS
=======

This issue was discovered by George Dunlap of Citrix.

RESOLUTION
==========

Applying the appropriate attached patch resolves this issue.

xsa160.patch               xen-unstable
xsa160-4.6.patch           Xen 4.5.x, 4.6.x
xsa160-4.4.patch           Xen 4.3.x, 4.4.x

$ sha256sum xsa160*
470811aeead5e942d6fedad5b4e21bee85f2160b022bcab315520014b6aa39a6  xsa160.patch
d0ce9e3c2b951ac3d25da4a0f6f232b13980625a249ed9c4cd6e9484721943a5  xsa160-4.4.patch
40362873b7fa2c1450596ef9ea23c73f80608b77ca50b89e62daf46c131fcee6  xsa160-4.6.patch
$

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
Team.


(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:
  http://www.xenproject.org/security-policy.html
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQEcBAEBAgAGBQJWZr8JAAoJEIP+FMlX6CvZfEYH/Rg7X9HdB+937h81tq30nrkE
/PazyPDB8DprHL0X/IjPEQFvGOazCf45uzSzkrPXaFwu27yhbAxx/m8s94FxUjWb
EiWwYKsb0Gh9OBejRkgiB3VMQmySWqkcjzUR1f2hk4iJ3yX8q2peRECK/Ba9aYPu
lHN9aycnh1ORPmWPUUo8cMFhRVag1P5E77mqrxXo2nfed23xDA5GeZceg8XoT67n
T2m59xAEwrSrHypb/XESuwtEU67CnowRcxlH7Z3EEk+ljvxOBvdovNp0yztOtArK
EnV3UAwM+YMXvoYB4YZUQ/q9tZ1dIgyeTosOSoNHI471lBYL9QTlO22bc4+qKCE=
=IjJr
-----END PGP SIGNATURE-----