[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