| Summary: | app-emulation/xen-4.6.4-r3, app-emulation/xen-tools-4.6.4-r4: loss of sensitive information (XSA-200) | ||
|---|---|---|---|
| Product: | Gentoo Security | Reporter: | Aaron Bauman (RETIRED) <bman> |
| Component: | Vulnerabilities | Assignee: | Gentoo Security <security> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | dlan |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | B4 [glsa cve] | ||
| Package list: | Runtime testing required: | --- | |
@maintainer, please proceed. This issue was resolved and addressed in GLSA 201612-56 at https://security.gentoo.org/glsa/201612-56 by GLSA coordinator Thomas Deutschmann (whissi). |
Xen Security Advisory XSA-200 x86 CMPXCHG8B emulation fails to ignore operand size override *** EMBARGOED UNTIL 2016-12-13 12:00 UTC *** ISSUE DESCRIPTION ================= The x86 instruction CMPXCHG8B is supposed to ignore legacy operand size overrides; it only honors the REX.W override (making it CMPXCHG16B). So, the operand size is always 8 or 16. When support for CMPXCHG16B emulation was added to the instruction emulator, this restriction on the set of possible operand sizes was relied on in some parts of the emulation; but a wrong, fully general, operand size value was used for other parts of the emulation. As a result, if a guest uses a supposedly-ignored operand size prefix, a small amount of hypervisor stack data is leaked to the guests: a 96 bit leak to guests running in 64-bit mode; or, a 32 bit leak to other guests. IMPACT ====== A malicious unprivileged guest may be able to obtain sensitive information from the host. VULNERABLE SYSTEMS ================== Xen versions 3.3 through 4.7 are affected. Xen master (to become 4.8) as well as Xen versions 3.2 and earlier are not affected. Only x86 systems are affected. ARM systems are not affected. On Xen 4.6 and earlier the vulnerability is exposed to all guest user processes, including unprivileged processes, in such guests. On Xen 4.7, the vulnerability is exposed only to guest user processes granted a degree of privilege (such as direct hardware access) by the guest administrator; or, to all user processes when the when the VM has been explicitly configured with a non-default cpu vendor string (in xm/xl, this would be done with a `cpuid=' domain config option). MITIGATION ========== There is no known mitigation. RESOLUTION ========== Applying the appropriate attached patch resolves this issue. xsa200-4.7.patch Xen 4.7.x xsa200-4.6.patch Xen 4.6.x, Xen 4.5.x, Xen 4.4.x $ sha256sum xsa200* 820e95e87b838de5eb4158a55c81cf205428f0ed17009dc8d45b2392cf9a0885 xsa200-4.6.patch d7113b94f6ef1c2849aedfe33eace85b0713fa83639c8a533fb289aa73e818e8 xsa200-4.7.patch $ 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