-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Xen Security Advisory CVE-2016-5403 / XSA-184 version 3 virtio: unbounded memory allocation issue UPDATES IN VERSION 3 ==================== Normalize version tags. ISSUE DESCRIPTION ================= 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. IMPACT ====== A malicious guest administrator can cause unbounded memory allocation in QEMU, which can cause an Out-of-Memory condition in the domain running qemu. Thus, a malicious guest administrator can cause a denial of service affecting the whole host. VULNERABLE SYSTEMS ================== 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.) MITIGATION ========== 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. CREDITS ======= This issue was discovered by Zhenhao Hong of the 360 Marvel Team. RESOLUTION ========== Applying the appropriate attached patch resolves this issue. xsa184-qemuu-master.patch qemu-xen 4.7.x, 4.6.x, 4.5.x, 4.4.x xsa184-qemut-master.patch qemu-xen-traditional 4.7.x, 4.6.x, 4.5.x, 4.4.x $ sha256sum xsa184* ea41a25dac82cc5c0ef8e599feb6ed400e99414110d4dba8017d6bd048bc3de4 xsa184-qemut-master.patch 2d675e5e08d9443cf2e5f3aa37521241d6ed898a602b5111d6969023e67b9b6b xsa184-qemuu-master.patch $ 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 administrators. 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 Team. (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: http://www.xenproject.org/security-policy.html -----BEGIN PGP SIGNATURE----- iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmV8b/MMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZmggH/0TZfcTH2LwTWpwzcYAe+H+EuPd+zcmepL2v4u+/ f2psVxtj1uNitxsm4dnbOz2K8TxcZUJRCO5xMJQWcOJTBdXpWvZEFFOhE8lIN4Jq ZbcLUeQfVbRvLugU7K9HHG43UGBBDTvoTBbdWBzM1REuPGEox0iZt/Swprig263y P7hrXTHSlP08uZJMW2ZuK3PG+JV8seQLTglC/KkuVpNURtfA2dwbbIqiwffPCigo 5ikyQNM3CU6+LDEyJ5eZ389TIktlR640NBnmbEBkydLd5eAcHL4z2qug+5NpmvSc zzc1rvCkDG0v910TOlOKrMZsE3+xI7CqQaO6yEkpWPdTSmg= =wK+W -----END PGP SIGNATURE-----