OracleVM 3.1 : xen (OVMSA-2012-0051)
Medium Nessus Plugin ID 79489
SynopsisThe remote OracleVM host is missing one or more security updates.
DescriptionThe remote OracleVM system is missing necessary patches to address critical security updates :
- 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.
[ Includes 25589:60f09d1ab1fe for CVE-2012-2625] (CVE-2012-4544)
- 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. (CVE-2012-4539)
- 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. (CVE-2012-4538)
- 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 BUGs and ASSERTs 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.
- 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.
- 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. (CVE-2012-4535)
- Correct RTC time offset update error for HVM guest changeset 24947:b198ada9689d
- 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.
SolutionUpdate the affected xen / xen-devel / xen-tools packages.