[Oraclevm-errata] OVMSA-2012-0035 : Oracle VM 3.0 xen security update

Errata Announcements for Oracle VM oraclevm-errata at oss.oracle.com
Thu Aug 9 14:15:06 PDT 2012


Oracle VM Security Advisory OVMSA-2012-0035

The following updated rpms for Oracle VM 3.0 have been uploaded to the 
Unbreakable Linux Network:

x86_64:
xen-4.0.0-81.el5.9.x86_64.rpm
xen-devel-4.0.0-81.el5.9.x86_64.rpm
xen-tools-4.0.0-81.el5.9.x86_64.rpm


SRPMS:
http://oss.oracle.com/oraclevm/server/3.0/SRPMS-updates/xen-4.0.0-81.el5.9.src.rpm


Description of changes:

[4.0.0-81.el5.9 ]
- Xen Security Advisory CVE-2012-3433 / XSA-11
   HVM guest destroy p2m teardown host DoS vulnerability
   An HVM guest is able to manipulate its physical address space such
   that tearing down the guest takes an extended period amount of
   time searching for shared pages.
   This causes the domain 0 VCPU which tears down the domain to be
   blocked in the destroy hypercall. This causes that domain 0 VCPU to
   become unavailable and may cause the domain 0 kernel to panic.
   There is no requirement for memory sharing to be in use.
   From the patch description:
   xen: only check for shared pages while any exist on teardown
   Avoids worst case behavour when guest has a large p2m.
   This is XSA-11 / CVE-2012-nnn
   Signed-off-by: Tim Deegan <tim at xen.org>
   Signed-off-by: Ian Campbell <ian.campbell at citrix.com>
   Tested-by: Olaf Hering <olaf at aepfle.de>
   Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com> [bug 
14396622]

[4.0.0-81.el5.8 ]
- Xen Security Advisory XSA-10
   HVM guest user mode MMIO emulation DoS vulnerability
   ISSUE DESCRIPTION
   =================
   Internal data of the emulator for MMIO operations may, under
   certain rare conditions, at the end of one emulation cycle be left
   in a state affecting a subsequent emulation such that this second
   emulation would fail, causing an exception to be reported to the
   guest kernel where none is expected.
   NOTE: No CVE number!
   The patch description is as follow:
   x86/hvm: don't leave emulator in inconsistent state
   The fact that handle_mmio(), and thus the instruction emulator, is
   being run through twice for emulations that require involvement of the
   device model, allows for the second run to see a different guest state
   than the first one. Since only the MMIO-specific emulation routines
   update the vCPU's io_state, if they get invoked on the second pass,
   internal state (and particularly this variable) can be left in a state
   making successful emulation of a subsequent MMIO operation impossible.
   Consequently, whenever the emulator invocation returns without
   requesting a retry of the guest instruction, reset io_state.
   Signed-off-by: Jan Beulich <jbeulich at suse.com>
   Acked-by: Keir Fraser <keir at xen.org>
   Signed-off-by: Chuck Anderson <chuck.anderson at oracle.com> [bug 14390643]




More information about the Oraclevm-errata mailing list