|Public release ||2015-08-03 12:00|
|Updated ||2015-08-03 12:37|
|Title ||QEMU leak of uninitialized heap memory in rtl8139 device model|
Filesadvisory-140.txt (signed advisory file)
-----BEGIN PGP SIGNED MESSAGE-----
Xen Security Advisory CVE-2015-5165 / XSA-140
QEMU leak of uninitialized heap memory in rtl8139 device model
UPDATES IN VERSION 2
Updated status of the patches.
The QEMU model of the RTL8139 network card did not sufficiently
validate inputs in the C+ mode offload emulation. This results in
uninitialised memory from the QEMU process's heap being leaked to the
domain as well as to the network.
A guest may be able to read sensitive host-level data relating to
itself which resides in the QEMU process.
Such information may include things such as information relating to
real devices backing emulated devices or passwords which the host
administrator does not intend to share with the guest admin.
All Xen systems running x86 HVM guests without stubdomains which have
been configured with an emulated RTL8139 driver model (which is the
default) are vulnerable.
Systems using qemu-dm stubdomain device models (for example, by
specifying "device_model_stubdomain_override=1" in xl's domain
configuration files) are NOT vulnerable.
Both the traditional ("qemu-xen-traditional") or upstream-based
("qemu-xen") qemu device models are potentially vulnerable.
Systems running only PV guests are NOT vulnerable.
ARM systems are NOT vulnerable.
The patches supplied by the Qemu Project are of course against recent
versions of qemu. They cannot be applied directly to
qemu-xen-traditional. The Xen Project Security Team do not feel we
have the resources to backport and qualify these substantial and
Users using qemu-xen-traditional with stub domains are not vulnerable,
because the stub dm is a deprivileged qemu guest instance.
Users using qemu-xen-traditional for compatibility with old guests can
avoid the vulnerability by switching to using a stub device model.
The Xen Project Security Team encourages users and downstreams who are
using qemu-xen-traditional and able to backport the patches to share
those patches with us, so that we may distribute them with an updated
We will encourage the community to have a conversation, when this
advisory is released, about the continuing security support status of
qemu-xen-traditional in non-stub-dm configurations.
Avoiding the use of emulated network devices altogether, by specifying
a PV only VIF in the domain configuration file will avoid this
Avoiding the use of the RTL8139 device in favour of other emulations
will also avoid this issue.
Enabling stubdomains will mitigate this issue, by reducing the
information leak to only information belonging to the service domain.
qemu-dm stubdomains are only available with the "qemu-xen-traditional"
device model version.
This issue was discovered by Donghai Zhu of Alibaba.
Applying the appropriate attached patches resolves this issue.
xsa140-qemuu-unstable-?.patch qemu-upstream, xen-unstable, Xen 4.5.x,
xsa140-qemuu-4.3-?.patch qemu-upstream, Xen 4.3.x, Xen 4.2.x
$ sha256sum xsa140*.patch
DEPLOYMENT DURING EMBARGO
Deployment of the patches 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: Deployment of any of the mitigations described above is NOT
permitted (except on systems used and administered 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 in all cases the configuration
change may be visible to the guest.
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
(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