|Public release ||2016-07-27 15:00|
|Updated ||2016-07-27 16:06|
|Title ||virtio: unbounded memory allocation issue|
Filesadvisory-184.txt (signed advisory file)
-----BEGIN PGP SIGNED MESSAGE-----
Xen Security Advisory CVE-2016-5403 / XSA-184
virtio: unbounded memory allocation issue
UPDATES IN VERSION 2
A guest can submit virtio requests without bothering to wait for
completion and is therefore not bound by virtqueue size. (This
requires reusing vring descriptors in more than one request, which is
incorrect but possible.) Processing a request allocates a
VirtQueueElement and therefore causes unbounded memory allocation
controlled by the guest.
A malicious guest administrator can cause unbounded memory allocation
in QEMU, which can cause an Out-of-Memory condition in the domain
Thus, a malicious guest administrator can cause a denial of service
affecting the whole host.
ARM systems are not vulnerable.
PV domains are not vulnerable.
Only HVM domains where virtio-net devices are provided to the guest
are vulnerable. Note that NO such devices are provided by default,
so the default configuration is not vulnerable.
HVM domains run with QEMU stub domains are not vulnerable.
(Note that all virtio subsystems are affected; but only virtio-net is
a supported configuration. See docs/misc/qemu-xen-security.)
Running PV only will avoid the issue.
Running HVM domains with Xen PV drivers instead of virtio-net will
avoid the issue.
Running HVM domains with with stubdomains will mitigate the issue.
This issue was discovered by Zhenhao Hong of the 360 Marvel Team.
Applying the appropriate attached patch resolves this issue.
xsa184-qemuu-master.patch qemu-upstream, Xen unstable, 4.7.x, 4.6.x, 4.5.x, 4.4.x
xsa184-qemut-master.patch qemu-traditional, Xen unstable, 4.7.x, 4.6.x, 4.5.x, 4.4.x
$ sha256sum xsa184*
NOTES ON THE EMBARGO PERIOD
Note that the embargo period is shorter than normal as the Xen
Security team were only notified of the issue on 25 July.
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
-----END PGP SIGNATURE-----
Xenproject.org Security Team