ISSUE DESCRIPTION ================= In CIRRUS_BLTMODE_MEMSYSSRC mode the bitblit copy routine cirrus_bitblt_cputovideo fails to check wethehr the specified memory region is safe. IMPACT ====== A malicious guest administrator can cause an out of bounds memory write, very likely exploitable as a privilege escalation. VULNERABLE SYSTEMS ================== Versions of qemu shipped with all Xen versions are vulnerable. Xen systems running on x86 with HVM guests, with the qemu process running in dom0 are vulnerable. Only guests provided with the "cirrus" emulated video card can exploit the vulnerability. The non-default "stdvga" emulated video card is not vulnerable. (With xl the emulated video card is controlled by the "stdvga=" and "vga=" domain configuration options.) ARM systems are not vulnerable. Systems using only PV guests are not vulnerable. For VMs whose qemu process is running in a stub domain, a successful attacker will only gain the privileges of that stubdom, which should be only over the guest itself. Both upstream-based versions of qemu (device_model_version="qemu-xen") and `traditional' qemu (device_model_version="qemu-xen-traditional") are vulnerable. MITIGATION ========== Running only PV guests will avoid the issue. Running HVM guests with the device model in a stubdomain will mitigate the issue. Changing the video card emulation to stdvga (stdvga=1, vga="stdvga", in the xl domain configuration) will avoid the vulnerability. 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. However, deployment of the "stdvga" mitigation (changing the video card emulation to stdvga) 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 this produces a guest-visible change which will indicate which component contains the vulnerability. Additionally, 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.)
I have pushed 2.8.0-r1 to the tree that contains the published upstream fix commit 62d4c6bd5263bb8413a06c80144fc678df6dfb64 Author: Li Qiang <liqiang6-s@360.cn> Date: Wed Feb 1 09:35:01 2017 +0100 cirrus: fix oob access issue (CVE-2017-2615) This specific patch is handled in bug #608034, stabilization on #608728
*ugh* I mixed up the CVEs. Please disregard my previous comment.
Patchset is prepared. I will push the patch for this bug (and the other open CVE patches) at precisely 12:00pm.
@ Maintainer(s): Please proceed!
commit cc47fc6cf1fef191ebb6c19d4b8bba9a12294024 Author: Matthias Maier <tamiko@gentoo.org> Date: Mon Feb 20 21:27:40 2017 -0600 app-emulation/qemu: security fixes, notably CVE-2017-2620, bug #609206 This commit applies a number of patches fixing CVE-2017-2620 #609206 CVE-2017-2630 #609396 CVE-2017-5973 #609334 CVE-2017-5987 #609398 CVE-2017-6058 #609638 Package-Manager: Portage-2.3.3, Repoman-2.3.1
Arches, please stabilize =app-emulation/qemu-2.8.0-r3 Target-keywords: "amd64 x86"
amd64 stable
x86 stable. Maintainer(s), please cleanup. Security, please add it to the existing request, or file a new one.
commit 6db0a37a742a067e1df7b6e82147f09289c0ebd1 Author: Matthias Maier <tamiko@gentoo.org> Date: Wed Feb 22 13:16:26 2017 -0600 app-emulation/qemu: remove vulnerable 2.8.0-r1, bug #609206 Package-Manager: Portage-2.3.3, Repoman-2.3.1
Arches and Maintainer(s), Thank you for your work. New GLSA Request filed.
This issue was resolved and addressed in GLSA 201704-01 at https://security.gentoo.org/glsa/201704-01 by GLSA coordinator Kristian Fiskerstrand (K_F).