|Public release ||2015-03-31 12:00|
|Updated ||2015-03-31 12:09|
|Title ||Long latency MMIO mapping operations are not preemptible|
Filesadvisory-125.txt (signed advisory file)
-----BEGIN PGP SIGNED MESSAGE-----
Xen Security Advisory CVE-2015-2752 / XSA-125
Long latency MMIO mapping operations are not preemptible
UPDATES IN VERSION 3
The XEN_DOMCTL_memory_mapping hypercall allows long running operations
without implementing preemption.
This hypercall is used by the device model as part of the emulation
associated with configuration of PCI devices passed through to HVM
guests and is therefore indirectly exposed to those guests.
This can cause a physical CPU to become busy for a significant period,
leading to a host denial of service in some cases.
If a host denial of service is not triggered then it may instead be
possible to deny service to the domain running the device model,
e.g. domain 0.
This hypercall is also exposed more generally to all
toolstacks. However the uses of it in libxl based toolstacks are not
believed to open up any avenue of attack from an untrusted
guest. Other toolstacks may be vulnerable however.
The vulnerability is exposed via HVM guests which have a PCI device
assigned to them. A malicious HVM guest in such a configuration can
mount a denial of service attack affecting the whole system via its
associated device model (qemu-dm).
A guest is able to trigger this hypercall via operations which it is
legitimately expected to perform, therefore running the device model
as a stub domain does not offer protection against the host denial of
service issue. However it does offer some protection against secondary
issues such as denial of service against dom0.
The issue is exposed via x86 HVM VMs which have been assigned a PCI
x86 PV domains, x86 HVM domains without passthrough devices and ARM
domains do not expose this vulnerability.
Xen 3.2.x and later are vulnerable.
Xen 3.1.x and earlier have not been inspected.
Running only PV guests will avoid this issue.
This issue can be avoided by not assigning devices with large MMIO
regions to untrusted HVM guests.
This issue was discovered by Konrad Rzeszutek Wilk of Oracle.
Applying the appropriate attached patch resolves this issue.
xsa125.patch Xen 4.5.x, xen-unstable
xsa125-4.4.patch Xen 4.4.x
xsa125-4.3.patch Xen 4.3.x
xsa125-4.2.patch Xen 4.2.x
$ sha256sum xsa125*.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
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