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

===========================================================================
             AUSCERT External Security Bulletin Redistribution

                               ESB-2015.2735
           Multiple vulnerabilities have been identified in Xen
                              2 November 2015

===========================================================================

        AusCERT Security Bulletin Summary
        ---------------------------------

Product:           Xen
Publisher:         Xen
Operating System:  Xen
                   UNIX variants (UNIX, Linux, OSX)
                   Windows
Impact/Access:     Denial of Service -- Existing Account
Resolution:        Patch/Upgrade
CVE Names:         CVE-2015-7972 CVE-2015-7971 CVE-2015-7970
                   CVE-2015-7969 CVE-2015-7814 CVE-2015-7813

Original Bulletin: 
   http://xenbits.xen.org/xsa/advisory-146.html
   http://xenbits.xen.org/xsa/advisory-147.html
   http://xenbits.xen.org/xsa/advisory-149.html
   http://xenbits.xen.org/xsa/advisory-150.html
   http://xenbits.xen.org/xsa/advisory-151.html
   http://xenbits.xen.org/xsa/advisory-152.html
   http://xenbits.xen.org/xsa/advisory-153.html

Comment: This bulletin contains seven (7) Xen security advisories.

- --------------------------BEGIN INCLUDED TEXT--------------------

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

            Xen Security Advisory CVE-2015-7813 / XSA-146
                              version 3

   arm: various unimplemented hypercalls log without rate limiting

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

Public release.

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

The HYPERVISOR_physdev_op hypercall and most suboperations of the
HYPERVISOR_hvm_op hypercall are not currently implemented by Xen on
ARM and when called will log the use to the hypervisor
console. However these guest accessible log messages are not
rate-limited.

IMPACT
======

A malicious guest could cause repeated logging to the hypervisor
console, leading to a Denial of Service attack.

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

Xen 4.4 and later systems running on ARM hardware are vulnerable.

x86 systems are not affected.

MITIGATION
==========

The problematic log messages are issued with priority Warning.

Therefore they can be rate limited by adding "loglvl=error/warning" to the
hypervisor command line or suppressed entirely by adding "loglvl=error".

On systems where the guest kernel is controlled by the host rather
than guest administrator, running only kernels which do not call these
hypercalls will also prevent untrusted guest users from exploiting
this issue. However untrusted guest administrators can still trigger
it unless further steps are taken to prevent them from loading code
into the kernel (e.g. by disabling loadable modules etc) or from using
other mechanisms which allow them to run code at kernel privilege.

CREDITS
=======

This issue was discovered by Julien Grall of Citrix.

RESOLUTION
==========

Applying the attached patch resolves this issue.

xsa146.patch        xen-unstable, Xen 4.6.x, Xen 4.5.x, Xen 4.4.x

$ sha256sum xsa146*.patch
1d0ff203581ac5bcc0ec4469a4909da968b218ed83280efd217020c396028591  xsa146.patch
$

DEPLOYMENT DURING EMBARGO
=========================

Deployment of the patches and/or mitigations described above (or
others which are substantially similar) is permitted during the
embargo, even on public-facing systems with untrusted guest users and
administrators.

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)

iQEcBAEBAgAGBQJWMgm1AAoJEIP+FMlX6CvZGjMH/iYvPwiZU0iKkgADyMBek6A6
fmkHlmd5z7EC7eSwKn2SzRcw8KsE9E4Hdo4IaPoWx+ElSKlHwteo8vdHq3zYXWsb
vpYFvlD5wiWRYpTDiBtDZC7cwOx1qqelDMwwN8k3p1g+eNqEB5VrfjVWWxp7xE6a
+gqEea9+ASJmZ1K3cczOGIzWSrGSGcC7v715nECCwBkquYlsdP8L7I+K2IiCL45i
ymRm+fD3CvDtLT+Q3ZG9I/C78CH5O4INATrdz6Syqtti+jPoYY7+6LmLZXR0tIk2
v47g/mAoDNwJAaWDfZL9GnzXTZIm+Lri+qh/4LkunnMGgHIF4Ah4HhsNJlX4h7M=
=lDV8
- -----END PGP SIGNATURE-----

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

            Xen Security Advisory CVE-2015-7814 / XSA-147
                              version 3

 arm: Race between domain destruction and memory allocation decrease

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

Public release.

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

While freeing the memory associated with a domain during domain
destruction Xen could race with a toolstack domain reducing the
amount of memory associated with that same domain via the
XENMEM_decrease_reservation.

In the case where this race is hit the host will crash.

The race is not exposed via the XENMEM_remove_from_physmap or
XENMEM_exchange interfaces.

IMPACT
======

Domains deliberately given partial management control may be able to
deny service by crashing the host.

Such a domain needs to be granted access to at least one of
XENMEM_decrease_reservation or XEN_DOMCTL_destroydomain over another
domain.

As a result, in a system designed to enhance security by radically
disaggregating the management, the security may be reduced.  But, the
security will be no worse than a non-disaggregated design.

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

This issue is only relevant to systems which intend to increase
security through the use of advanced disaggregated management
techniques.

This does not include systems using libxl, libvirt, or OpenStack
(unless substantially modified or supplemented, as compared to
versions supplied by the respective upstreams).

Only ARM systems are potentially affected.  All Xen versions which
support ARM are potentially affected.

x86 systems are not affected.

MITIGATION
==========

There is no known mitigation.

Switching from disaggregated to a non-disaggregated operation does NOT
mitigate these vulnerabilities.  Rather, it simply recategorises the
vulnerability to hostile management code, regarding it "as designed";
thus it merely reclassifies these issues as "not a bug".  Users and
vendors of disaggregated systems should not change their
configuration.

CREDITS
=======

This issue was discovered by Ian Campbell of Citrix.

RESOLUTION
==========

Applying the attached patch resolves this issue.

xsa147.patch        xen-unstable, Xen 4.6.x, Xen 4.5.x, Xen 4.4.x

$ sha256sum xsa147*.patch
35cd9c5dabd5af6756957cf7378d527b2fcbff35dcf578769769a364a98ea6ac  xsa147.patch
$

DEPLOYMENT DURING EMBARGO
=========================

Deployment of the patches and/or mitigations described above (or
others which are substantially similar) is permitted during the
embargo, even on public-facing systems with untrusted guest users and
administrators.

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)

iQEcBAEBAgAGBQJWMgm3AAoJEIP+FMlX6CvZHPAIAIgXu4741IJeO/Pb187gxO3Z
IXpSSJF1Fvof/Ma6LLSGRth94WiafF91MKKqlEAKFPyfRUOkJXHAoahDUe7lF1Lr
V5qSA4jAu69ZIhg3AAKuI+xBV/PNx7rlaG0duRI9nHmLRhbIU3EF9YJbKntdZzZr
gdE/zLk+moW4U2/quEIEQGqtDGr/RAm5N0MqGwW4mcHUhlp4XcNuqrC8+b5qaeJ3
8/pc9whzyHM04De5Ve9/iFUu0J6KxNK+hN9V14mO8bcPXzK/K8X4C3qUD6HtZx+U
VsaKT/N4INNDg7wqULcjg/Vp23SE/mUPM8Fernee9KnI2CY3pnS9DB1KEYMry5s=
=7g7l
- -----END PGP SIGNATURE-----

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

            Xen Security Advisory CVE-2015-7969 / XSA-149
                              version 3

              leak of main per-domain vcpu pointer array

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

Public release.

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

A domain's primary array of vcpu pointers can be allocated by a
toolstack exactly once in the lifetime of a domain via the
XEN_DOMCTL_max_vcpus hypercall.

This array is leaked on domain teardown.  This memory leak could --
over time -- exhaust the host's memory.

IMPACT
======

A domain given partial management control via XEN_DOMCTL_max_vcpus can
mount a denial of service attack affecting the whole system.

The ability to also restart or create suitable domains is also
required to fully exploit the issue.  Without this the leak is limited
to a small multiple of the maximum number of vcpus for the domain.

The maximum leak is 64kbytes per domain (re)boot (less on ARM).

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

This issue is only relevant to systems which intend to increase
security through the use of advanced disaggregated management
techniques.

This does not include systems using libxl, libvirt, or OpenStack
(unless substantially modified or supplemented, as compared to
versions supplied by the respective upstreams).

Versions of Xen from 4.0 onwards are vulnerable.

All architectures are affected.

MITIGATION
==========

The leak is small.  Preventing the creation of large numbers of new
domains, and limiting the number of times an existing domain can be
rebooted, can reduce the impact of this vulnerability.

Switching from disaggregated to a non-disaggregated operation does NOT
mitigate the XEN_DOMCTL_max_vcpus vulnerability.  Rather, it simply
recategorises the vulnerability to hostile management code, regarding
it "as designed"; thus it merely reclassifies these issues as "not a
bug".  Users and vendors of disaggregated systems should not change
their configuration.

NOTE REGARDING CVE
==================

Note that CVE-2015-7969 covers both this issue and XSA-151.

CREDITS
=======

This issue was discovered by Ian Campbell of Citrix.

RESOLUTION
==========

Applying the attached patch resolves this issue.
(To resolve CVE-2015-7969, the patch from XSA-151 is required too.)

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

$ sha256sum xsa149*.patch
e01628400b81c4bb7bafba348f2ecb1fe80f16e3162cee5013e0be1d7311738b  xsa149.patch
$

DEPLOYMENT DURING EMBARGO
=========================

Deployment of the PATCH (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 (RE)BOOT LIMIT MITIGATION 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 applying domain creation and reboot limits in
connection with a security issue would be a user-visible change which
could lead to the rediscovery of the vulnerability.

Deployment of the mitigation is permitted only AFTER the embargo ends.


Also: 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)

iQEcBAEBAgAGBQJWMgm7AAoJEIP+FMlX6CvZ5EEH/RpWXVKVpA5JdTGGfWan9ojV
+9Froz+RdUJmINLHE/sIIAudfCIlc7zA1Ap/ukSUC9YfBZvjwMpiouTz2IJV+kgp
C0zTjTHrqf0RG7k9aXKTqDNhHWP/FukVv6V4KZ+vmC9CluV8ODhnvogO0bS4wO2y
dzJAtQZxhD1r0rgvLWlT0Wq0LylTqW6mXg0lHiBv+HFonKJAIEeg/0dJbriKsc0N
1+vI4DujVzE1Q3LuhkGtaxdGyZ/4rcfMexmIYHzpvehHLXKa63oHg7IGX2SchiKb
YFumc9K3sYdv+AHkqM9FdtKEgDvwcHL9+d4YVgGfQm9ukh2onEC6uw7VeVnPlXY=
=/Ww0
- -----END PGP SIGNATURE-----

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

             Xen Security Advisory CVE-2015-7970 / XSA-150
                               version 5

    x86: Long latency populate-on-demand operation is not preemptible

UPDATES IN VERSION 5
====================

Updated patch.  Compared to the version in XSA-150 v4 and earlier,
this patch is simpler and involves less rearrangement of the code.  It
is therefore thought to be less risky.  However, both this version and
the earlier versions have been tested, and both versions eliminate the
vulnerability.  Readers who have already prepared updates with, and/or
deployed, the earlier patch, do not necessarily need to update.

Public release.

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

When running an HVM domain in Populate-on-Demand mode, Xen would
sometimes search the domain for memory to reclaim, in response to
demands for population of other pages in the same domain.

This search runs without preemption.  The guest can, by suitable
arrangement of its memory contents, create a situation where this
search is a time-consuming linear scan of the guest's address space.

The scan might be triggered by the guest's own actions, or by
toolstack operations such as migration.  In guests affected by
XSA-153, this scan might be triggered simply by memory pressure in the
guest.

Even guests not started in PoD mode can create PoD entries.

IMPACT
======

A malicious HVM guest administrator can cause a denial of service.
Specifically, prevent use of a physical CPU for a significant period.

If a host watchdog (Xen or dom0) is in use, this can lead to a
watchdog timeout and consequently a reboot of the host.  If another,
innocent, guest, is configured with a watchdog, this issue can lead to
a reboot of such a guest.

In guests affected by XSA-153, this vulnerability may also be
triggered by an unprivileged guest user, simply by imposing a workload
which generates memory pressure.

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

The vulnerability is exposed to any x86 HVM guest.

ARM is not vulnerable.  x86 PV VMs are not vulnerable.

Versions of Xen from 3.4 onwards are affected.

MITIGATION
==========

Running only PV guests will avoid this issue.

On systems not also vulnerable to XSA-153, the vulnerability can be
avoided by ensuring that only trusted guest kernels are used, and that
further steps are taken to prevent a guest administrator from loading
code into the kernel (e.g. by disabling loadable modules etc) or from
using other mechanisms which allow them to run code at kernel
privilege.

CREDITS
=======

This is issue was disclosed by Andrew Cooper of Citrix.

RESOLUTION
==========

Attached is a patch which resolves the issue by limiting the
long-running "sweep" operation.

This patch will resolve the issue on systems where PoD is not
intentionally in use.  (Ie, where all HVM guests are started with
memory==maxmem.)


When PoD is in use, there are concerns that there may be situations --
operating systems not tested, or buggy balloon drivers, for example --
where limiting the long-running operation may cause guests to crash
which may otherwise not.

Therefore, the patch should be used with caution.

This patch can interact badly on configurations vulnerable to XSA-153.
XSA-153 is triggerable by unprivileged guest users.  The patch changes
the consequences from a host-wide CPU denial problem (which might be
tolerated without catastrophic symptoms in some configurations) into a
likely guest crash; thus it limits the scope of the consequences to
the specific guest, but may worsen the severity.


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

$ sha256sum xsa150*
9054215f08cab48d2523efb456eb3c93ca6ac580d661f6e4f1feca115c67afa8  xsa150.patch
$

DEPLOYMENT DURING EMBARGO
=========================

Deployment of the patches and/or mitigations described above (or
others which are substantially similar) is permitted during the
embargo, even on public-facing systems with untrusted guest users and
administrators.

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)

iQEcBAEBAgAGBQJWMgobAAoJEIP+FMlX6CvZ7W4H/36Bx6Aj+4PX3kLPwzsheejj
CWpOQjM4BZAVWkv1N9QInJagZ87qRFwFGlM8FzDuGy3dE7Df5MCs/BH9B1xrJ0E9
Ur30mpsw1IAf9YF/l/XlNLf9G6XCo/g2yS7Jfv5qk3953+0ZkqSd7t8ekFaQSKUz
GGOkhQKJuFsnEmimQTLLBt6brHaYfFJtnbKIFzcBQtRExlKI3BYk3OHNLvIUlj6X
MGij0fJTJggvGjaZ+Olthf0GLtDIZ8GbWD+0FQ4bJwEAacSJ1eVOYzVAdNfFIuVv
73MyN8QyEgu+HSc9RJnILV/g7oIfuGazo1A19KAjeImd81W4bQDVnZJ1KCkcbd0=
=ISHR
- -----END PGP SIGNATURE-----

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

            Xen Security Advisory CVE-2015-7969 / XSA-151
                              version 3

       x86: leak of per-domain profiling-related vcpu pointer array

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

Public release.

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

A domain's xenoprofile state contains an array of per-vcpu
information, which is allocated once in the lifetime of a domain in
response to that domain using the XENOPROF_get_buffer hypercall on
itself or by a domain with the privilege to profile a target domain
using the XENOPROF_set_passive hypercall.

This array is leaked on domain teardown.  This memory leak could --
over time -- exhaust the host's memory.

IMPACT
======

The following parties can mount a denial of service attack affecting
the whole system:

  - A malicious guest administrator via XENOPROF_get_buffer.
  - A domain given suitable privilege over another domain
    via XENOPROF_set_passive (this would usually be a domain being
    used to profile another domain, eg with the xenoprof tool).

The ability to also restart or create suitable domains is also
required to fully exploit the issue.  Without this the leak is limited
to a small multiple of the maximum number of vcpus for the domain.

The maximum leak is 128kbytes per domain (re)boot.

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

Versions of Xen from 4.0 onwards are vulnerable.

The XENOPROF hypercalls are only implemented on x86.  ARM is therefore
not vulnerable.

MITIGATION
==========

On systems where the guest kernel is controlled by the host rather
than guest administrator, running only kernels (in the target and
profiling domain respectively) which do not call these hypercalls will
also prevent untrusted guest users from exploiting this issue. However
untrusted guest administrators can still trigger it unless further
steps are taken to prevent them from loading code into the kernel
(e.g. by disabling loadable modules etc) or from using other
mechanisms which allow them to run code at kernel privilege.

The leak is small.  Preventing the creation of large numbers of new
domains, and limiting the number of times an existing domain can be
rebooted, can reduce the impact of this vulnerability.

NOTE REGARDING CVE
==================

Note that CVE-2015-7969 covers both this issue and XSA-149.

CREDITS
=======

This issue was discovered by Jan Beulich of SUSE.

RESOLUTION
==========

Applying the appropriate attached patch resolves this issue.
(To resolve CVE-2015-7969, the patch from XSA-149 is required too.)

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

$ sha256sum xsa151*.patch
e247a9dbbe236ffa3c5aa5e2d41047fa67da80f2b0474eef3440b5b3da2d5617  xsa151.patch
$

DEPLOYMENT DURING EMBARGO
=========================

Deployment of the PATCH or the TRUSTED KERNEL MITIGATION (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 (RE)BOOT LIMIT MITIGATION 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 applying domain creation and reboot limits in
connection with a security issue would be a user-visible change which
could lead to the rediscovery of the vulnerability.

Deployment of the reboot mitigation is permitted only AFTER the
embargo ends.


Also: 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)

iQEcBAEBAgAGBQJWMgm9AAoJEIP+FMlX6CvZticH+waAPTUnRA9CTnPs1BDjiTcc
kBuVb8ouvffinj+FCVQ/CIC1IAkClU8vBcOb3NAe9/PaCYPe9OlAxpvAAxxlgr05
N1Py8rBUEemKcCS9T4jTT2TNLYm9lzFihcTMOp+Y2diavcdmnhXj+kjO/FpD7tG/
TRDBnCVsxA4m+yxQJO8xXWIE+lYCoF+42Qc8Dyi2tcaN4WaBjjD5DyqNHIuf1ISF
DljnT3TsgDIlxmgeQsufX0VIh45FdZXExOmGAgRS3JCn0cTmQwONecyM5NjKaljZ
LEwk5sMSRa4cmb8naJRxPf30CydjmLBMdzU8KRjg+d6M46jTGTV794k/AKc4VxI=
=u9LH
- -----END PGP SIGNATURE-----

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

            Xen Security Advisory CVE-2015-7971 / XSA-152
                              version 3

      x86: some pmu and profiling hypercalls log without rate limiting

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

Public release.

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

HYPERCALL_xenoprof_op and HYPERVISOR_xenpmu_op log some errors and
attempts at invalid operations.

These log messages are not rate-limited, even though they can be
triggered by guests.

IMPACT
======

A malicious guest could cause repeated logging to the hypervisor
console, leading to a Denial of Service attack.

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

Xen versions 3.2.x and later are affected.  (The VPMU part of the
vulnerability is applicable only to Xen 4.6 and later.)

ARM systems are not affected.  (The pmu hypercall is x86-specific, and
xenoprof is not supported on ARM.)

MITIGATION
==========

The problematic log messages are issued with priority Warning.
Therefore they can be rate limited by adding "loglvl=error/warning" to
the hypervisor command line or suppressed entirely by adding
"loglvl=error".

On systems where the guest kernel is controlled by the host rather
than guest administrator, running only kernels which do not call these
hypercalls will also prevent untrusted guest users from exploiting
this issue. However untrusted guest administrators can still trigger
it unless further steps are taken to prevent them from loading code
into the kernel (e.g. by disabling loadable modules etc) or from using
other mechanisms which allow them to run code at kernel privilege.

CREDITS
=======

This issue was discovered by Jan Beulich of SUSE.

RESOLUTION
==========

Applying the appropriate attached patch resolves this issue.

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

$ sha256sum xsa152*.patch
596f51797aa591b5abd068ead03e21215cf70997c98a4a562392499afe47b81c  xsa152.patch
7ae2811ea80da29ee234ad5a2cbb5908e03db8fb6c50774d378d77d273e74e39  xsa152-4.5.patch
$

DEPLOYMENT DURING EMBARGO
=========================

Deployment of the patches and/or mitigations described above (or
others which are substantially similar) is permitted during the
embargo, even on public-facing systems with untrusted guest users and
administrators.

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)

iQEcBAEBAgAGBQJWMgm/AAoJEIP+FMlX6CvZzPwIAJs/NTew5AJA3bTO6QZtVC2T
sRt2F11prjjeklrAcqSC03q2bBpyylLB6PJ1jmmtT0MKtST5BszGA+sJt3G8nxw1
XKN8zNX5Yzfmltgi6ZeWk/1ps6kceb4evhkIUzt1v8Ttge148rEedGrJD9eLeRht
XdZr8ujXwP3NGBAesKNf0DugPTR7diYyUzvwven+OXVPg0ZT53t1r6Xref7Vl4p6
5b9uOK3rh/QVRbPGTOA1vzObk0MssBTGA615JGG0da4fr4vVUQsVK/MV/N6oc4fJ
iUHUcH83ldLGB9kt3+kq1S6KBESInriytPrKxNFvaKOrPlaOTOKRGvJSW0QZpos=
=BsWE
- -----END PGP SIGNATURE-----

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

            Xen Security Advisory CVE-2015-7972 / XSA-153
                              version 3

     x86: populate-on-demand balloon size inaccuracy can crash guests

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

Public release.

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

The design of the memory populate-on-demand (PoD) system requires that
a guest's memory ballooning driver reach its memory reduction target.
The target is not entirely well-defined in terms of the information
visible to the appropriate parts of the system, so some unknown set of
guests (but probably most guests) will fail this criterion.

If the guest memory balloon driver does not free sufficient memory to
reach its target, the guest will proceed to run with a nonzero number
of outstanding PoD pages.  When the guest or management toolstack
touches such a page, the hypervisor would search the guest memory for
a page containing only zeroes.

If no such page is found, the guest crashes.  Prior to the patch for
XSA-150, the search might lock up the relevant physical cpu for a
while.  After the patch to XSA-150, it might crash the guest even if a
suitable zero page is available.

This means that in the current arrangements toolstack software must
apply an adjustment to a guest's PoD target as supplied to Xen.
Neither xend nor libxl do this.

IMPACT
======

Guests configured with PoD might be unstable, especially under load.

In an affected guest, an unprivileged guest user might be able to
cause a guest crash, perhaps simply by applying load so as to cause
heavy memory pressure within the guest.

This problem also allows an unprivileged guest user to exercise the
separate vulnerability described in XSA-150: an unprivileged guest
user might be able to cause a denial of service affecting the host.

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

The vulnerability is restricted to HVM guests which have been
constructed in Populate-on-Demand mode (ie, with memory < maxmem).

ARM is not vulnerable.  x86 PV VMs are not vulnerable.  x86 HVM
domains without PoD (ie started with memory==maxmem, or without
mentioning "maxmem" in the guest config file) are not vulnerable.

Systems using libxl (whether via xl, or libvirt, or another higher
layer) or xend (whether via xm, or libvirt, or another higher layer)
are vulnerable.

If the system has been stress-tested (by imposing memory load on the
guest) and found to be stable, it is less likely that the guest is
vulnerable.

Combinations of Xen, guest, guest balloon driver, and toolstack
software, which have an empirical adjustment as described in the
Description, and which have been formally stress-tested in PoD mode,
are less likely to be vulnerable.

Migration is not capable of creating a guest with outstanding PoD.  So
migrating a guest which is vulnerable might crash it.  However, if a
guest has been migrated successfully since it booted, it is no longer
vulnerable.

Xen versions back to 3.4.x are affected.

Vulnerability of a particular guest can be tested by the host
administrator using the utility `xsa153-check.c', attached to this
advisory.


MITIGATION
==========

Reducing the guest's memory target, after guest startup, can cause the
guest's ballon driver to eliminate the PoD discrepancy.  If the guest
successfully balloons down, it will no longer be vulnerable.

On systems using libxl this can be done with `xl mem-set', during or
after each guest boot:

   # ./xsa153-check `xl domid name-of-guest`
   checked domain 621 for XSA-153: VULNERABLE (1 more outstanding pages)
   try using   xl mem-set   to reduce its memory by 1 (Mby)
   or perhaps reduce /local/domain/621/memory/target by 4
   # xl list name-of-guest
   Name                  ID   Mem VCPUs      State   Time(s)
   name-of-guest        621   512     2     r-----     156.9
   # xl mem-set name-of-guest 511
   #
   [ wait for guest to give up memory ]
   # ./xsa153-check `xl domid name-of-guest`
   checked domain 621 for XSA-153: NOT vulnerable
   #

Alternatively, no matter the toolstack, it is possible for a host
administrator to bypass the toolstack code and give ballooning
instructions directly to the guest:

   [ suppose guest domid is 616, eg from xl domid name-of-guest  ]
   # ./xsa153-check 616
   checked domain 616 for XSA-153: VULNERABLE (1 more outstanding pages)
   try using   xl mem-set   to reduce its memory by 1 (Mby)
   or perhaps reduce /local/domain/616/memory/target by 4
   # xenstore-read /local/domain/616/memory/target
   520188
   # xenstore-write /local/domain/616/memory/target 520184
   #
   [ wait for guest to give up memory ]
   # ./xsa153-check `xl domid name-of-guest`
   checked domain 616 for XSA-153: NOT vulnerable
   #

The memory/target value is in decimal, and is a number of kilobytes;
it must be a multiple of 4, since a page is 4 Kb on affected systems.
The value to write should be some amount less than the value read.


It is not currently known whether use of the VM memory event
inspection facilities (in-tree, this means the xc_monitor utility)
might invalidate the workaround.


Note that guests may become unstable if given too little memory, so
large reductions of the memory target should be applied with caution,
if at all.  The expected offset related to XSA-153 is small (tens of
pages, perhaps).  If a large reduction is required, it is more likely
that either the guest is still booting up (and still working to reduce
the PoD memory), or that the guest's balloon driver is not
functioning:

   # ./xsa153-check `xl domid name-of-guest`
   checked domain 623 for XSA-153: VULNERABLE (65536 more outstanding pages)
   difference is >1Mby
   ballon driver not running or guest still booting?
   #

A guest without a working balloon driver will be unstable in PoD mode,
especially under memory pressure; this is an inherent feature of the
design of PoD.


RESOLUTION
==========

The attached patch fixes the problem for systems using libxl (via xl,
or via libvirt, or another higher layer).  At the time of writing
there is no patch for xend-based systems.

xsa153-libxl.patch            xen-unstable, Xen 4.5, Xen 4.6
xsa153-libxl.patch            Xen 4.1 to 4.4 inclusive, using libxl

(Xend was removed in Xen 4.5; so the libxl-only patch is always
sufficient for Xen 4.5 and later.)

$ sha256sum xsa153*
633df5d970af49476c2d279e604150c444834bb906f6568070f0c2e0ceaa3af4  xsa153-check.c
f5cbc98cba758e10da0a01d9379012ec56b98a85a92bfeb0c6b8132d4b91ce77  xsa153-libxl.patch
$

DEPLOYMENT DURING EMBARGO
=========================

Deployment of the patches and/or mitigations described above (or
others which are substantially similar) is permitted during the
embargo, even on public-facing systems with untrusted guest users and
administrators.

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


NOTE REGARDING SHORT EMBARGO
============================

This issue was quickly encountered by the Security Team during our
investigations of the scope and impact of XSA-150; this issue was
originally discussed in the `Incomplete Information' section of
XSA-150 v1.  Accordingly XSA-153 is embargoed and the embargo will
end at the same time as that of XSA-150.
- -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQEcBAEBAgAGBQJWMgofAAoJEIP+FMlX6CvZaqUIAIzgbftJMwo2ywcWycAGzeDS
5iseCaCqx1OD8a00m+WvXTLX/yKKJQrgTJkDlJfgqEb4Y2NoVRUKShApSHsbFrFa
qeocl7ipBdXTYk0FZZrsBd/aCjQgL/NlYf0BCaV+tpPuehOBgJwWpIf4RltOQVkv
MxfRCGee52yUbWyFykmlKK3fxfGi4wXfMGN6zS9FXpudIBxjedRS4gyksERusXS7
hcRNEcLNzeQA+4PUmpkOzwS/NrtWiIU265kaHFsMUO8HbxcFgzFJ+15G0GK8JgY5
9XE0XWxn/B5Uc7IMiDxcFYT79C87XXvH4ctFArN9MJqss/ko0H25fz+Te8iWigc=
=vBPN
- -----END PGP SIGNATURE-----

- --------------------------END INCLUDED TEXT--------------------

You have received this e-mail bulletin as a result of your organisation's
registration with AusCERT. The mailing list you are subscribed to is
maintained within your organisation, so if you do not wish to continue
receiving these bulletins you should contact your local IT manager. If
you do not know who that is, please send an email to auscert@auscert.org.au
and we will forward your request to the appropriate person.

NOTE: Third Party Rights
This security bulletin is provided as a service to AusCERT's members.  As
AusCERT did not write the document quoted above, AusCERT has had no control
over its content. The decision to follow or act on information or advice
contained in this security bulletin is the responsibility of each user or
organisation, and should be considered in accordance with your organisation's
site policies and procedures. AusCERT takes no responsibility for consequences
which may arise from following or acting on information or advice contained in
this security bulletin.

NOTE: This is only the original release of the security bulletin.  It may
not be updated when updates to the original are made.  If downloading at
a later date, it is recommended that the bulletin is retrieved directly
from the author's website to ensure that the information is still current.

Contact information for the authors of the original document is included
in the Security Bulletin above.  If you have any questions or need further
information, please contact them directly.

Previous advisories and external security bulletins can be retrieved from:

        http://www.auscert.org.au/render.html?cid=1980

===========================================================================
Australian Computer Emergency Response Team
The University of Queensland
Brisbane
Qld 4072

Internet Email: auscert@auscert.org.au
Facsimile:      (07) 3365 7031
Telephone:      (07) 3365 4417 (International: +61 7 3365 4417)
                AusCERT personnel answer during Queensland business hours
                which are GMT+10:00 (AEST).
                On call after hours for member emergencies only.
===========================================================================
-----BEGIN PGP SIGNATURE-----
Comment: http://www.auscert.org.au/render.html?it=1967

iQIVAwUBVjcIz36ZAP0PgtI9AQJDLRAAiZDJ8YuDYaugjGtiihmV4HTtjUMZAQbq
MgTtJ1xbKGgEXj9o/5WsNhx3LWk77Vu0B+C5HKOvRiGNiE7iK/YaJkR9/BNsJeSz
tBJx+PwmmqAgOUaf4Fk+GNf67VYPzazLqHHXH2zHWMpTLNbe1Hw7Y00Q2RC8gp+p
hAkxeUxF/nipcWZF+xM5LQ9IQtkGSU8svVQHmm/Or6NgrKE8eTtmURtQLVlvnxP+
V9kJ3VSM3e0bqdmV1lzIbniaqfxbmrh2QWIwCadIXHT77JqqfGWm+XkUPtygoz1k
Nsb/BvYZPo+nIBB4daR8E9bJv+QUkcuJi+9SuRFP+1y6GKl/WaFAay8EK+QtWaeo
HDdBUI1Xzn1jtcLccz0XVs2KmRdoM+WXXB2iTL/pW+H2Huei0hBuy8n6MdDI69s0
jPS9nNIPkeKFDcSB+Y6Ku4RUMmAv+k/SZGfVHkrnPQe2iR84R9KigpwK4VmWkE9n
hQCC0gW2XNcMbv6YlXr4GsE4XK7VaWV/4Pbt6PtPalcGeebEMdk92MTq36V2DKDT
dEEhMtfQtSD5TxLCSqixarQjJh4LmSXfpsSEqj7csJ3HlgxHuy3/+MbTCNb3IpXv
XH6bT4LnHP7Ylkvkc8u4TnuzWtlpdyE9tJu08A+RWYPokvdUU1LcN7lxuu8pwWIF
8IhSX/mVMbY=
=EzdE
-----END PGP SIGNATURE-----