From http://www.openwall.com/lists/oss-security/2014/09/23/2: Xen Security Advisory XSA-104 version 2 Race condition in HVMOP_track_dirty_vram UPDATES IN VERSION 2 ==================== Public Release. ISSUE DESCRIPTION ================= The routine controlling the setup of dirty video RAM tracking latches the value of a pointer before taking the respective guarding lock, thus making it possible for a stale pointer to be used by the time the lock got acquired and the pointer gets dereferenced. The hypercall providing access to the affected function is available to the domain controlling HVM guests. IMPACT ====== Malicious or buggy stub domain kernels or tool stacks otherwise living outside of Domain0 can mount a denial of service attack which, if successful, can affect the whole system. Only domains controlling HVM guests can exploit this vulnerability. (This includes domains providing hardware emulation services to HVM guests.) VULNERABLE SYSTEMS ================== Xen versions from 4.0.0 onwards are vulnerable. This vulnerability is only applicable to Xen systems using stub domains or other forms of disaggregation of control domains for HVM guests. MITIGATION ========== There is no mitigation available for this issue. (The security of a Xen system using stub domains is still better than with a qemu-dm running as an unrestricted dom0 process. Therefore users with these configurations should not switch to an unrestricted dom0 qemu-dm.) CREDITS ======= This issue was discovered by Andrew Cooper at Citrix. RESOLUTION ========== Applying the attached patch resolves this issue. xsa104.patch xen-unstable, Xen 4.4.x, Xen 4.3.x, Xen 4.2.x From http://www.openwall.com/lists/oss-security/2014/09/23/4: Xen Security Advisory XSA-105 version 2 Missing privilege level checks in x86 HLT, LGDT, LIDT, and LMSW emulation UPDATES IN VERSION 2 ==================== Public Release. Convert patch line endings from DOS to Unix style. ISSUE DESCRIPTION ================= The emulation of the instructions HLT, LGDT, LIDT, and LMSW fails to perform supervisor mode permission checks. However these instructions are not usually handled by the emulator. Exceptions to this are - - when the instruction's memory operand (if any) lives in (emulated or passed through) memory mapped IO space, - - in the case of guests running in 32-bit PAE mode, when such an instruction is (in execution flow) within four instructions of one doing a page table update, - - when an Invalid Opcode exception gets raised by a guest instruction, and the guest then (likely maliciously) alters the instruction to become one of the affected ones. Malicious guest user mode code may be able to leverage this to install e.g. its own Interrupt Descriptor Table (IDT). IMPACT ====== Malicious HVM guest user mode code may be able to crash the guest or escalate its own privilege to guest kernel mode. VULNERABLE SYSTEMS ================== Xen versions from at least 3.2.x onwards are vulnerable. Older versions have not been inspected. Only user processes in HVM guests can take advantage of this vulnerability. MITIGATION ========== Running only PV guests will avoid this issue. There is no mitigation available for HVM guests. CREDITS ======= This issue was discovered Andrei Lutas at BitDefender and analyzed by Andrew Cooper at Citrix. RESOLUTION ========== Applying the attached patch resolves this issue. xsa105.patch xen-unstable, Xen 4.4.x, Xen 4.3.x, Xen 4.2.x From http://www.openwall.com/lists/oss-security/2014/09/23/3: Xen Security Advisory XSA-106 version 2 Missing privilege level checks in x86 emulation of software interrupts UPDATES IN VERSION 2 ==================== Public Release. ISSUE DESCRIPTION ================= The emulation of instructions which generate software interrupts fails to perform supervisor mode permission checks. However these instructions are not usually handled by the emulator. Exceptions to this are - - when a memory operand (implicit for the affected instructions) lives in (emulated or passed through) memory mapped IO space, - - in the case of guests running in 32-bit PAE mode, when such an instruction is (in execution flow) within four instructions of one doing a page table update, - - when an Invalid Opcode exception gets raised by a guest instruction, and the guest then (likely maliciously) alters the instruction to become one of the affected ones, - - when the guest is in real mode (in which case there are no privilege checks anyway). IMPACT ====== Malicious HVM guest user mode code may be able to crash the guest. VULNERABLE SYSTEMS ================== Xen versions from 3.3 onwards are vulnerable. Only user processes in HVM guests can take advantage of this vulnerability. MITIGATION ========== Running only PV guests will avoid this issue. There is no mitigation available for HVM guests. CREDITS ======= This issue was discovered Andrei Lutas at BitDefender and analyzed by Andrew Cooper at Citrix. RESOLUTION ========== Applying the attached patch resolves this issue. xsa106.patch xen-unstable, Xen 4.4.x, Xen 4.3.x, Xen 4.2.x @maintainer(s): after the bump, in case we need to stabilize the package, please let us know if it is ready for the stabilization or not.
fixed in xen-4.4.1-r2 xen-4.3.3-r1 xen-4.2.5-r1 please see bug 524200
Arches and Mainter(s), Thank you for your work. Added to an existing GLSA request.
CVE-2014-7156 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2014-7156): The x86_emulate function in arch/x86/x86_emulate/x86_emulate.c in Xen 3.3.x through 4.4.x does not check the supervisor mode permissions for instructions that generate software interrupts, which allows local HVM guest users to cause a denial of service (guest crash) via unspecified vectors. CVE-2014-7155 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2014-7155): The x86_emulate function in arch/x86/x86_emulate/x86_emulate.c in Xen 4.4.x and earlier does not properly check supervisor mode permissions, which allows local HVM users to cause a denial of service (guest crash) or gain guest kernel mode privileges via vectors involving an (1) HLT, (2) LGDT, (3) LIDT, or (4) LMSW instruction. CVE-2014-7154 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2014-7154): Race condition in HVMOP_track_dirty_vram in Xen 4.0.0 through 4.4.x does not ensure possession of the guarding lock for dirty video RAM tracking, which allows certain local guest domains to cause a denial of service via unspecified vectors.
This issue was resolved and addressed in GLSA 201412-42 at http://security.gentoo.org/glsa/glsa-201412-42.xml by GLSA coordinator Yury German (BlueKnight).
