[Oraclevm-errata] OVMSA-2017-0178 Important: Oracle VM 3.2 xen security update

Errata Announcements for Oracle VM oraclevm-errata at oss.oracle.com
Wed Dec 13 17:49:03 PST 2017


Oracle VM Security Advisory OVMSA-2017-0178

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


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



Description of changes:

[4.1.3-25.el5.223.99]
- From 2a99aa99fc84a45f505f84802af56b006d14c52e Mon Sep 17 00:00:00 2001
   From: Andrew Cooper <andrew.cooper3 at citrix.com>
   Date: Fri, 19 Aug 2016 15:08:10 +0100
   Subject: [PATCH] xen/physmap: Do not permit a guest to populate PoD 
pages for itself
   PoD is supposed to be entirely transparent to guest, but this 
interface has
   been left exposed for a long time.
   The use of PoD requires careful co-ordination by the toolstack with the
   XENMEM_{get,set}_pod_target hypercalls, and xenstore ballooning 
target.  The
   best a guest can do without toolstack cooperation crash.
   Furthermore, there are combinations of features (e.g. c/s c63868ff 
"libxl:
   disallow PCI device assignment for HVM guest when PoD is enabled") 
which a
   toolstack might wish to explicitly prohibit (in this case, because 
the two
   simply don't function in combination).  In such cases, the guest 
mustn't be
   able to subvert the configuration chosen by the toolstack.
   Signed-off-by: Andrew Cooper <andrew.cooper3 at citrix.com>
   Acked-by: Jan Beulich <jbeulich at suse.com>
   Conflict:
   xen/common/memory.c
   Signed-off-by: Zhenzhong Duan <zhenzhong.duan at oracle.com> [bug 27120669]
- Due to the history performance reason, we decide to disable PoD feature
   in old OVM product. Please don't set maxmem>memory
   XSA-246,XSA-247 [bug 27120669] {CVE-2017-17044,CVE-2017-17045}

[4.1.3-25.el5.223.98]
- x86/shadow: correct SH_LINEAR mapping detection in sh_guess_wrmap()
   The fix for XSA-243 / CVE-2017-15592 (c/s bf2b4eadcf379) introduced a 
change
   in behaviour for sh_guest_wrmap(), where it had to cope with no 
shadow linear
   mapping being present.
   As the name suggests, guest_vtable is a mapping of the guests 
pagetable, not
   Xen's pagetable, meaning that it isn't the pagetable we need to check 
for the
   shadow linear slot in.
   The practical upshot is that a shadow HVM vcpu which switches into 
4-level
   paging mode, with an L4 pagetable that contains a mapping which 
aliases Xen's
   SH_LINEAR_PT_VIRT_START will fool the safety check for whether a 
SHADOW_LINEAR
   mapping is present.  As the check passes (when it should have 
failed), Xen
   subsequently falls over the missing mapping with a pagefault such as:
   (XEN) Pagetable walk from ffff8140a0503880:
   (XEN)  L4[0x102] = 000000046c218063 ffffffffffffffff
   (XEN)  L3[0x102] = 000000046c218063 ffffffffffffffff
   (XEN)  L2[0x102] = 000000046c218063 ffffffffffffffff
   (XEN)  L1[0x103] = 0000000000000000 ffffffffffffffff
   This is part of XSA-243.
   Signed-off-by: Andrew Cooper <andrew.cooper3 at citrix.com>
   Reviewed-by: Tim Deegan <tim at xen.org>
   Backported-by: Zhenzhong Duan <zhenzhong.duan at oracle.com> [bug 
26976552] {CVE-2017-15592}

[4.1.3-25.el5.223.97]
- dpci: Fix a race during unbinding of MSI interrupt
   The check of hvm_irq_dpci->mapping and read of flags are not 
protected in same
   critical area, so the unbind of MSI interrupt may intercepts between 
them.
   Like below scene:
   CPU0                              CPU1
   ----                              ----
   hvm_do_IRQ_dpci()
   !test_bit(mirq, dpci->mapping))
   return 0;
   spin_lock(&d->event_lock);
   hvm_irq_dpci->mirq[machine_gsi].flags = 0;
   clear_bit(machine_gsi, hvm_irq_dpci->mapping);
   spin_unlock(&d->event_lock);
   <SoftIRQ>
   hvm_dirq_assist()
   spin_lock(&d->event_lock);
   if ( pt_irq_need_timer(hvm_irq_dpci->mirq[pirq].flags) )
   set_timer();
   spin_unlock(&d->event_lock);
   Then set_timer() is mistakenly called which access uninitialized 
timer struct.
   Then page fault happen and a backtrace like below:
   (XEN) Xen call trace:
   (XEN)    [<ffff82c480124c92>] set_timer+0x92/0x170
   (XEN)    [<ffff82c48013bb03>] hvm_dirq_assist+0x1c3/0x1e0
   (XEN)    [<ffff82c4801235ff>] do_tasklet_work_percpu+0x7f/0x120
   (XEN)    [<ffff82c480121915>] __do_softirq+0x65/0x90
   (XEN)    [<ffff82c4801f7fb6>] process_softirqs+0x6/0x10
   (XEN)
   (XEN) Pagetable walk from 0000000000000008:
   (XEN)  L4[0x000] = 0000002104cc1067 0000000000289430
   (XEN)  L3[0x000] = 000000212ecd8067 00000000002b3447
   (XEN)  L2[0x000] = 0000000000000000 ffffffffffffffff
   (XEN)
   (XEN) ****************************************
   (XEN) Panic on CPU 41:
   (XEN) FATAL PAGE FAULT
   (XEN) [error_code=0002]
   (XEN) Faulting linear address: 0000000000000008
   (XEN) ****************************************
   This issue is OVM3.2 only as OVM3.3 or above already has similar fix in
   pt_pirq_iterate()
   Signed-off-by: Zhenzhong Duan <zhenzhong.duan at oracle.com>
   Reviewed-by: Joe Jin <joe.jin at oracle.com>
   Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com> [bug 
26896681]




More information about the Oraclevm-errata mailing list