[Oraclevm-errata] OVMSA-2018-0225 Important: Oracle VM 3.2 xen security update

[Errata Announcements for Oracle VM]

Oracle VM Security Advisory OVMSA-2018-0225

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.170.x86_64.rpm
xen-devel-4.1.3-25.el5.223.170.x86_64.rpm
xen-tools-4.1.3-25.el5.223.170.x86_64.rpm


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



Description of changes:

[4.1.3-25.el5.223.170]
- From: Jan Beulich <jbeulich at suse.com>
   Subject: x86/paging: don't unconditionally BUG() on finding 
SHARED_M2P_ENTRY
   PV guests can fully control the values written into the P2M.
   This is XSA-251.
   Signed-off-by: Jan Beulich <jbeulich at suse.com>
   Reviewed-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 
27188660] {CVE-2017-17565}

[4.1.3-25.el5.223.169]
- From: Jan Beulich <jbeulich at suse.com>
   Subject: x86/shadow: fix ref-counting error handling
   The old-Linux handling in shadow_set_l4e() mistakenly ORed together the
   results of sh_get_ref() and sh_pin(). As the latter failing is not a
   correctness problem, simply ignore its return value.
   In sh_set_toplevel_shadow() a failing sh_get_ref() must not be
   accompanied by installing the entry, despite the domain being crashed.
   This is XSA-250.
   Signed-off-by: Jan Beulich <jbeulich at suse.com>
   Reviewed-by: Tim Deegan <tim at xen.org>
   Backported-by: Zhenzhong Duan <zhenzhong.duan at oracle.com>
   Reviewed-by: Boris Ostrovsky <boris.ostrovsky at oracle.com> [bug 
27188654] {CVE-2017-17564}

[4.1.3-25.el5.223.168]
- From: Jan Beulich <jbeulich at suse.com>
   Subject: x86/shadow: fix refcount overflow check
   Commit c385d27079 ("x86 shadow: for multi-page shadows, explicitly track
   the first page") reduced the refcount width to 25, without adjusting the
   overflow check. Eliminate the disconnect by using a manifest constant.
   Interestingly, up to commit 047782fa01 ("Out-of-sync L1 shadows: OOS
   snapshot") the refcount was 27 bits wide, yet the check was already
   using 26.
   This is XSA-249.
   v2: Simplify expression back to the style it was.
   Signed-off-by: Jan Beulich <jbeulich at suse.com>
   Reviewed-by: George Dunlap <george.dunlap at citrix.com>
   Reviewed-by: Tim Deegan <tim at xen.org>
   Backported-by: Zhenzhong Duan <zhenzhong.duan at oracle.com>
   Reviewed-by: Boris Ostrovsky <boris.ostrovsky at oracle.com> [bug 
27188648] {CVE-2017-17563}

[4.1.3-25.el5.223.167]
- From: Jan Beulich <jbeulich at suse.com>
   Subject: x86/mm: don't wrongly set page ownership
   PV domains can obtain mappings of any pages owned by the correct domain,
   including ones that aren't actually assigned as "normal" RAM, but used
   by Xen internally.  At the moment such "internal" pages marked as owned
   by a guest include pages used to track logdirty bits, as well as p2m
   pages and the "unpaged pagetable" for HVM guests. Since the PV memory
   management and shadow code conflict in their use of struct page_info
   fields, and since shadow code is being used for log-dirty handling for
   PV domains, pages coming from the shadow pool must, for PV domains, not
   have the domain set as their owner.
   While the change could be done conditionally for just the PV case in
   shadow code, do it unconditionally (and for consistency also for HAP),
   just to be on the safe side.
   There's one special case though for shadow code: The page table used for
   running a HVM guest in unpaged mode is subject to get_page() (in
   set_shadow_status()) and hence must have its owner set.
   This is XSA-248.
   Signed-off-by: Jan Beulich <jbeulich at suse.com>
   Reviewed-by: Tim Deegan <tim at xen.org>
   Reviewed-by: George Dunlap <george.dunlap at citrix.com>
   Conflict:
   xen/arch/x86/mm/hap/hap.c
   xen/arch/x86/mm/shadow/common.c
   Backported-by: Zhenzhong Duan <zhenzhong.duan at oracle.com>
   Reviewed-by: Boris Ostrovsky <boris.ostrovsky at oracle.com> [bug 
27188645] {CVE-2017-17566}