|Public release ||2015-10-29 11:59|
|Updated ||2015-10-29 11:59|
|Title ||x86: Long latency populate-on-demand operation is not preemptible|
Filesadvisory-150.txt (signed advisory file)
-----BEGIN PGP SIGNED MESSAGE-----
Xen Security Advisory CVE-2015-7970 / XSA-150
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.
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
Even guests not started in PoD mode can create PoD entries.
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.
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.
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
This is issue was disclosed by Andrew Cooper of Citrix.
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
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*
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
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