[Oraclevm-errata] OVMSA-2012-0051 Important: Oracle VM 3.1 xen security update
Errata Announcements for Oracle VM
oraclevm-errata at oss.oracle.com
Tue Nov 13 16:18:37 PST 2012
Oracle VM Security Advisory OVMSA-2012-0051
The following updated rpms for Oracle VM 3.1 have been uploaded to the
Unbreakable Linux Network:
x86_64:
xen-4.1.2-18.el5.24.x86_64.rpm
xen-devel-4.1.2-18.el5.24.x86_64.rpm
xen-tools-4.1.2-18.el5.24.x86_64.rpm
SRPMS:
http://oss.oracle.com/oraclevm/server/3.1/SRPMS-updates/xen-4.1.2-18.el5.24.src.rpm
Description of changes:
[4.1.2-18.el5.24]
- libxc: builder: limit maximum size of kernel/ramdisk.
Allowing user supplied kernels of arbitrary sizes, especially during
decompression, can swallow up dom0 memory leading to either virtual
address space exhaustion in the builder process or allocation
failures/OOM killing of both toolstack and unrelated processes.
We disable these checks when building in a stub domain for pvgrub
since this uses the guest's own memory and is isolated.
Decompression of gzip compressed kernels and ramdisks has been safe
since 14954:58205257517d (Xen 3.1.0 onwards).
This is XSA-25 / CVE-2012-4544.
Also make explicit checks for buffer overflows in various
decompression routines. These were already ruled out due to other
properties of the code but check them as a belt-and-braces measure.
Signed-off-by: Ian Campbell <ian.campbell at citrix.com>
Acked-by: Ian Jackson <ian.jackson at eu.citrix.com>
[ Includes 25589:60f09d1ab1fe for CVE-2012-2625]
Signed-off-by: Chuck Anderson <chuck.anderson at oracle.com>
Reviewed-by: John Haxby <john.haxby at oracle.com> [bug 14812640]
{CVE-2012-4544}
[4.1.2-18.el5.23]
- compat/gnttab: Prevent infinite loop in compat code
c/s 20281:95ea2052b41b, which introduces Grant Table version 2
hypercalls introduces a vulnerability whereby the compat hypercall
handler can fall into an infinite loop.
If the watchdog is enabled, Xen will die after the timeout.
This is a security problem, XSA-24 / CVE-2012-4539.
Signed-off-by: Andrew Cooper <andrew.cooper3 at citrix.com>
Acked-by: Jan Beulich <jbeulich at suse.com>
Acked-by: Ian Jackson <ian.jackson at eu.citrix.com>
Signed-off-by: Chuck Anderson <chuck.anderson at oracle.com>
Reviewed-by: John Haxby <john.haxby at oracle.com> [bug 14809075]
{CVE-2012-4539}
[4.1.2-18.el5.22]
- xen/mm/shadow: check toplevel pagetables are present before unhooking
them.
If the guest has not fully populated its top-level PAE entries when
it calls
HVMOP_pagetable_dying, the shadow code could try to unhook entries from
MFN 0. Add a check to avoid that case.
This issue was introduced by c/s 21239:b9d2db109cf5.
This is a security problem, XSA-23 / CVE-2012-4538.
Signed-off-by: Tim Deegan <tim at xen.org>
Tested-by: Andrew Cooper <andrew.cooper3 at citrix.com>
Acked-by: Ian Campbell <ian.campbell at citrix.com>
Signed-off-by: Chuck Anderson <chuck.anderson at oracle.com>
Reviewed-by: John Haxby <john.haxby at oracle.com> [bug 14809055]
{CVE-2012-4538}
[4.1.2-18.el5.21]
- x86/physmap: Prevent incorrect updates of m2p mappings
In certain conditions, such as low memory, set_p2m_entry() can fail.
Currently, the p2m and m2p tables will get out of sync because we still
update the m2p table after the p2m update has failed.
If that happens, subsequent guest-invoked memory operations can cause
BUG()s and ASSERT()s to kill Xen.
This is fixed by only updating the m2p table iff the p2m was
successfully updated.
This is a security problem, XSA-22 / CVE-2012-4537.
Signed-off-by: Andrew Cooper <andrew.cooper3 at citrix.com>
Acked-by: Ian Campbell <ian.campbell at citrix.com>
Acked-by: Ian Jackson <ian.jackson at eu.citrix.com>
Signed-off-by: Chuck Anderson <chuck.anderson at oracle.com>
Reviewed-by: John Haxby <john.haxby at oracle.com> [bug 14809010]
{CVE-2012-4537}
[4.1.2-18.el5.20]
- x86/physdev: Range check pirq parameter from guests
Otherwise Xen will read beyond either end of the struct
domain.arch.pirq_emuirq array, usually resulting in a fatal page fault.
This vulnerability was introduced by c/s 23241:d21100f1d00e, which adds
a call to domain_pirq_to_emuirq() which uses the guest provided pirq
value before range checking it, and was fixed by c/s 23573:584c2e5e03d9
which changed the behaviour of the domain_pirq_to_emuirq() macro to use
radix trees instead of a flat array.
This is XSA-21 / CVE-2012-4536.
Signed-off-by: Andrew Cooper <andrew.cooper3 at citrix.com>
Acked-by: Jan Beulich <jbeulich at suse.com>
Acked-by: Ian Campbell <ian.campbell at citrix.com>
Signed-off-by: Chuck Anderson <chuck.anderson at oracle.com>
Reviewed-by: John Haxby <john.haxby at oracle.com> [bug 14808999]
{CVE-2012-4536}
[4.1.2-18.el5.19]
- VCPU/timers: Prevent overflow in calculations, leading to DoS
vulnerability
The timer action for a vcpu periodic timer is to calculate the next
expiry time, and to reinsert itself into the timer queue. If the
deadline ends up in the past, Xen never leaves __do_softirq(). The
affected PCPU will stay in an infinite loop until Xen is killed by the
watchdog (if enabled).
This is a security problem, XSA-20 / CVE-2012-4535.
Signed-off-by: Andrew Cooper <andrew.cooper3 at citrix.com>
Acked-by: Ian Campbell <ian.campbell at citrix.com>
Signed-off-by: Chuck Anderson <chuck.anderson at oracle.com> [bug
14808914] {CVE-2012-4535}
[4.1.2-18.el5.18]
- Correct RTC time offset update error for HVM guest
changeset 24947:b198ada9689d
Signed-off-by: Adnan Misherfi <adnan.misherfi at oracle.com>
Backported-by: Joe Jin <joe.jin at oracle.com> [bug 15846562]
[4.1.2-18.el5.17]
- always release vm running lock on VM shutdown
Before this patch, when xend restarted, the VM running lock will not
be released
on shutdown, so the VM could never start again.
Talked with Junjie, we recommend always releasing the lock on VM
shutdown. So
even when xend restarted, there should be no stale lock leaving there.
Backported-by: Joe Jin <joe.jin at oracle.com>
Signed-off-by: Zhigang Wang <zhigang.x.wang at oracle.com>
Signed-off-by: Adnan Misherfi <adnan.misherfi at oracle.com>
Signed-off-by: Junjie Wei <junjie.wei at oracle.com>
Signed-off-by: Kurt Hackel <kurt.hackel at oracle.com> [bug 14799467]
More information about the Oraclevm-errata
mailing list