[Oraclevm-errata] OVMSA-2016-0090 Important: Oracle VM 3.2 xen security update

Wed Jul 27 12:20:04 PDT 2016

Oracle VM Security Advisory OVMSA-2016-0090

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

x86_64:
xen-4.1.3-25.el5.223.34.x86_64.rpm
xen-devel-4.1.3-25.el5.223.34.x86_64.rpm
xen-tools-4.1.3-25.el5.223.34.x86_64.rpm

SRPMS:
http://oss.oracle.com/oraclevm/server/3.2/SRPMS-updates/xen-4.1.3-25.el5.223.34.src.rpm

Description of changes:

[4.1.3-25.el5.223.34]
- x86/HVM: correct CPUID leaf 80000008 handling - 6c733e54
   xsa173_01_0001-x86-HVM-correct-CPUID-leaf-80000008-handling.patch was 
based
   on upstream commit:
   ef437690af8b75e6758dce77af75a22b63982883
   x86/HVM: correct CPUID leaf 80000008 handling
   It should have been based on upstream commit:
   6c733e549889a9b8c4e03140348b8e00241d4ce9
   x86/HVM: correct CPUID leaf 80000008 handling
   The changes in this patch are the differences between those two patches.
   Signed-off-by: Chuck Anderson <chuck.anderson at oracle.com>
   Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com>
   Reviewed-by: Boris Ostrovsky <boris.ostrovsky at oracle.com> [bug 24356444]

[4.1.3-25.el5.223.33]
- x86/pv: Remove unsafe bits from the mod_l?_entry() fastpath
   All changes in writeability and cacheability must go through full
   re-validation.
   Rework the logic as a whitelist, to make it clearer to follow.
   This is XSA-182
   Signed-off-by: Andrew Cooper <andrew.cooper3 at citrix.com>
   Reviewed-by: Tim Deegan <tim at xen.org>
   Upstream commit 798c1498f764bfaa7b0b955bab40b01b0610d372
   Conflicts:
   xen/include/asm-x86/page.h
   Backported-by: Zhenzhong Duan <zhenzhong.duan at oracle.com>
   Reviewed-by: Boris Ostrovsky <boris.ostrovsky at oracle.com> [bug 24307902]

[4.1.3-25.el5.223.32]
- x86/mm: fully honor PS bits in guest page table walks
   In L4 entries it is currently unconditionally reserved (and hence
   should, when set, always result in a reserved bit page fault), and is
   reserved on hardware not supporting 1Gb pages (and hence should, when
   set, similarly cause a reserved bit page fault on such hardware).
   This is CVE-2016-4480 / XSA-176.
   Signed-off-by: Jan Beulich <jbeulich at suse.com>
   Reviewed-by: Andrew Cooper <andrew.cooper3 at citrix.com>
   Tested-by: Andrew Cooper <andrew.cooper3 at citrix.com>
   Backported-by: Zhenzhong Duan <zhenzhong.duan at oracle.com>
   Reviewed-by: Boris Ostrovsky <boris.ostrovsky at oracle.com> [bug 
23531409] {CVE-2016-4480}

[4.1.3-25.el5.223.31]
- x86/mm: Handle 1GiB superpages in the pagetable walker.
   This allows HAP guests to use 1GiB superpages.  Shadow and PV guests
   still can't use them without more support in shadow/* and mm.c.
   Signed-off-by: Christoph Egger <Christoph.Egger at amd.com>
   Signed-off-by: Tim Deegan <Tim.Deegan at citrix.com>
   Conflicts:
   xen/arch/x86/hvm/hvm.c
   xen/arch/x86/mm/guest_walk.c
   Backported from upstream commit 96b740e209d0bea4c16d93211ceb139fc98d10c2
   Backported-by: Zhenzhong Duan <zhenzhong.duan at oracle.com>
   Reviewed-by: Boris Ostrovsky <boris.ostrovsky at oracle.com> [bug 
23531409] {CVE-2016-4480}

[4.1.3-25.el5.223.30]
- main loop: Big hammer to fix logfile disk DoS in Xen setups
   Each time round the main loop, we now fstat stderr.  If it is too big,
   we dup2 /dev/null onto it.  This is not a very pretty patch but it is
   very simple, easy to see that it's correct, and has a low risk of
   collateral damage.
   The limit is 1Mby by default but can be adjusted by setting a new
   environment variable.
   This fixes CVE-2014-3672.
   Signed-off-by: Ian Jackson <Ian.Jackson at eu.citrix.com>
   Tested-by: Ian Jackson <Ian.Jackson at eu.citrix.com>
   Backported-by: Zhenzhong Duan <zhenzhong.duan at oracle.com> [bug 
23531487] {CVE-2014-3672}

[4.1.3-25.el5.223.29]
- x86: make hvm_cpuid() tolerate NULL pointers
   Now that other HVM code started making more extensive use of
   hvm_cpuid(), let's not force every caller to declare dummy variables
   for output not cared about.
   Signed-off-by: Jan Beulich <jbeulich at suse.com>
   Reviewed-by: Andrew Cooper <andrew.cooper3 at citrix.com>
   Acked-by: Boris Ostrovsky <boris.ostrovsky at oracle.com>
   Acked-by: Jun Nakajima <jun.nakajima at intel.com>
   xen/arch/x86/hvm/svm/svm.c and xen/arch/x86/hvm/vmx/vvmx.c part are 
removed as
   no source matched.
   Upstream commit 11b85dbd0ab068bad3beadda3aee2298205a3c01
   Signed-off-by: Zhenzhong Duan <Zhenzhong.duan at oracle.com> [bug 23500509]

[4.1.3-25.el5.223.28]
- x86: limit GFNs to 32 bits for shadowed superpages.
   Superpage shadows store the shadowed GFN in the backpointer field,
   which for non-BIGMEM builds is 32 bits wide.  Shadowing a superpage
   mapping of a guest-physical address above 2^44 would lead to the GFN
   being truncated there, and a crash when we come to remove the shadow
   from the hash table.
   Track the valid width of a GFN for each guest, including reporting it
   through CPUID, and enforce it in the shadow pagetables.  Set the
   maximum witth to 32 for guests where this truncation could occur.
   This is XSA-173.
   Signed-off-by: Tim Deegan <tim at xen.org>
   Signed-off-by: Jan Beulich <jbeulich at suse.com>
   Reported-by: Ling Liu <liuling-it at 360.cn>
   Conflicts:
   xen/arch/x86/cpu/common.c
   arch/x86/mm/guest_walk.c
   Upstream commit 95dd1b6e87b61222fc856724a5d828c9bdc30c80
   Backported-by: Zhenzhong Duan <zhenzhong.duan at oracle.com>
   Reviewed-by: Boris Ostrovsky <boris.ostrovsky at oracle.com> [bug 
23170585] {CVE-2016-3960}

[4.1.3-25.el5.223.27]
- x86/HVM: correct CPUID leaf 80000008 handling
   CPUID[80000008].EAX[23:16] have been given the meaning of the guest
   physical address restriction (in case it needs to be smaller than the
   host's), hence we need to mirror that into vCPUID[80000008].EAX[7:0].
   Enforce a lower limit at the same time, as well as a fixed value for
   the virtual address bits, and zero for the guest physical address ones.
   In order for the vMTRR code to see these overrides we need to make it
   call hvm_cpuid() instead of domain_cpuid(), which in turn requires
   special casing (and relaxing) the controlling domain.
   This additionally should hide an ordering problem in the tools: Both
   xend and xl appear to be restoring a guest from its image before
   setting up the CPUID policy in the hypervisor, resulting in
   domain_cpuid() returning all zeros and hence the check in
   mtrr_var_range_msr_set() failing if the guest previously had more than
   the minimum 36 physical address bits.
   Signed-off-by: Jan Beulich <jbeulich at suse.com>
   Reviewed-by: Tim Deegan <tim at xen.org>
   Conflicts:
   xen/arch/x86/hvm/mtrr.c
   Upstream commit ef437690af8b75e6758dce77af75a22b63982883
   Backported-by: Zhenzhong Duan <zhenzhong.duan at oracle.com>
   Reviewed-by: Boris Ostrovsky <boris.ostrovsky at oracle.com> [bug 
23170585] {CVE-2016-3960}