|Public release ||2015-11-30 06:00|
|Updated ||2015-11-30 10:54|
|Title ||heap buffer overflow vulnerability in pcnet emulator|
Filesadvisory-162.txt (signed advisory file)
-----BEGIN PGP SIGNED MESSAGE-----
Xen Security Advisory CVE-2015-7504 / XSA-162
heap buffer overflow vulnerability in pcnet emulator
UPDATES IN VERSION 2
Correct cut and paste reference to bootloaders in "DEPLOYMENT DURING
EMBARGO" section, which should have instead referred to the
The QEMU security team has predisclosed the following advisory:
The AMD PC-Net II emulator(hw/net/pcnet.c), while receiving
packets in loopback mode, appends CRC code to the receive
buffer. If the data size given is same as the buffer size(4096),
the appended CRC code overwrites 4 bytes after the s->buffer,
making the adjacent 's->irq' object point to a new location.
A guest which has access to an emulated PCNET network device
(e.g. with "model=pcnet" in their VIF configuration) can exploit this
vulnerability to take over the qemu process elevating its privilege to
that of the qemu process.
All Xen systems running x86 HVM guests without stubdomains which have
been configured to use the PCNET emulated driver model are
The default configuration is NOT vulnerable (because it does not
emulate PCNET NICs).
Systems running only PV guests are NOT 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" or upstream qemu device models are
ARM systems are NOT vulnerable.
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 PCNET device in favour of other emulations
will also avoid this issue.
Enabling stubdomains will mitigate this issue, by reducing the
escalation to only those privileges accorded to the service domain.
qemu-dm stubdomains are only available with the traditional "qemu-xen"
The QEMU security team have supplied the attached xsa162-qemuu.patch
which it is believed will resolve the issue. However this patch has
not undergone the usual reviews and has not yet been accepted by QEMU
The backports were created by the Xen Project security team on the same
xsa162-qemuu.patch qemu upstream, Xen unstable, 4.6.x, 4.5.x, 4.4.x
xsa162-qemuu-4.3.patch Xen 4.3.x
xsa162-qemut-4.3.patch qemu-xen-traditional, Xen unstable, 4.5.x, 4.4.x, 4.3.x
$ sha256sum xsa162*
This issue was discovered by Qinghao Tang of the Qihoo 360 Marvel
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 in all cases the configuration change may be visible
to the guest 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
(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