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

Errata Announcements for Oracle VM oraclevm-errata at oss.oracle.com
Tue Jun 21 10:11:18 PDT 2016


Oracle VM Security Advisory OVMSA-2016-0081

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


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



Description of changes:

[4.1.3-25.el5.223.26]
- Revert "x86/HVM: correct CPUID leaf 80000008 handling"
   Originally added by Oracle bug 23170585
   Signed-off-by: Chuck Anderson <chuck.anderson at oracle.com> [bug 23500509]

[4.1.3-25.el5.223.25]
- Revert "x86: limit GFNs to 32 bits for shadowed superpages."
   Originally added through Oracle bug 23170585.
   Signed-off-by: Chuck Anderson <chuck.anderson at oracle.com>
   Reviewed-by: Joe Jin <joe.jin at oracle.com> [bug 23500509]

[4.1.3-25.el5.223.24]
- vga: make sure vga register setup for vbe stays intact
   (CVE-2016-3712).
   Call vbe_update_vgaregs() when the guest touches GFX, SEQ or CRT
   registers, to make sure the vga registers will always have the
   values needed by vbe mode.  This makes sure the sanity checks
   applied by vbe_fixup_regs() are effective.
   Without this guests can muck with shift_control, can turn on planar
   vga modes or text mode emulation while VBE is active, making qemu
   take code paths meant for CGA compatibility, but with the very
   large display widths and heigts settable using VBE registers.
   Which is good for one or another buffer overflow.  Not that
   critical as they typically read overflows happening somewhere
   in the display code.  So guests can DoS by crashing qemu with a
   segfault, but it is probably not possible to break out of the VM.
   Fixes: CVE-2016-3712
   Reported-by: Zuozhi Fzz <zuozhi.fzz at alibaba-inc.com>
   Reported-by: P J P <ppandit at redhat.com>
   Signed-off-by: Gerd Hoffmann <kraxel at redhat.com>
   [Backport to qemu-xen-tradition]
   Signed-off-by: Andrew Cooper <andrew.cooper3 at citrix.com>
   Upstream commit 0b0cf8110e97b0cbd0da73d11163e26978822757
   Backported-by: Zhenzhong Duan <zhenzhong.duan at oracle.com>
   Reviewed-by: Boris Ostrovsky <boris.ostrovsky at oracle.com> [bug 
23263192] {CVE-2016-3712}

[4.1.3-25.el5.223.23]
- vga: update vga register setup on vbe changes
   Call the new vbe_update_vgaregs() function on vbe configuration
   changes, to make sure vga registers are up-to-date.
   Signed-off-by: Gerd Hoffmann <kraxel at redhat.com>
   [Backport to qemu-xen-tradition]
   Signed-off-by: Andrew Cooper <andrew.cooper3 at citrix.com>
   Upstream commit 5e840e6292825fcae90f6750a8f57bc989e28c5f
   Backported-by: Zhenzhong Duan <zhenzhong.duan at oracle.com>
   Reviewed-by: Boris Ostrovsky <boris.ostrovsky at oracle.com> [bug 
23263192] {CVE-2016-3712}

[4.1.3-25.el5.223.22]
- vga: factor out vga register setup
   When enabling vbe mode qemu will setup a bunch of vga registers to make
   sure the vga emulation operates in correct mode for a linear
   framebuffer.  Move that code to a separate function so we can call it
   from other places too.
   Signed-off-by: Gerd Hoffmann <kraxel at redhat.com>
   [Backport to qemu-xen-tradition]
   Signed-off-by: Andrew Cooper <andrew.cooper3 at citrix.com>
   Upstream commit df228023ce39e8b72bd5a198b8703319b8b9ca23
   Backported-by: Zhenzhong Duan <zhenzhong.duan at oracle.com>
   Reviewed-by: Boris Ostrovsky <boris.ostrovsky at oracle.com> [bug 
23263192] {CVE-2016-3712}

[4.1.3-25.el5.223.21]
- -kes code a bit easier to read.
   Signed-off-by: Gerd Hoffmann <kraxel at redhat.com>
   [Backport to qemu-xen-tradition]
   Signed-off-by: Andrew Cooper <andrew.cooper3 at citrix.com>
   Upstream commit 34db09fb9967441408a1ff0579d553222cf17441
   Backported-by: Zhenzhong Duan <zhenzhong.duan at oracle.com>
   Reviewed-by: Boris Ostrovsky <boris.ostrovsky at oracle.com>
   -This line, and those below, will be ignored--
   M      tools/ioemu-remote/hw/vga.c [bug 23263192]

[4.1.3-25.el5.223.20]
- CVE-2014-3615: vbe: rework sanity checks
   Backport of qemu-upstream:
   * c1b886c45dc70f247300f549dce9833f3fa2def5
   Signed-off-by: Andrew Cooper <andrew.cooper3 at citrix.com>
   Upstream commit 8a1e383df25477e21b48c67c93c3a4dde19f9e4f
   Backported-by: Zhenzhong Duan <zhenzhong.duan at oracle.com>
   Reviewed-by: Boris Ostrovsky <boris.ostrovsky at oracle.com> [bug 
23263192] {CVE-2016-3712}

[4.1.3-25.el5.223.19]
- vga: fix banked access bounds checking (CVE-2016-3710)
   vga allows banked access to video memory using the window at 0xa00000
   and it supports a different access modes with different address
   calculations.
   The VBE bochs extentions support banked access too, using the
   VBE_DISPI_INDEX_BANK register.  The code tries to take the different
   address calculations into account and applies different limits to
   VBE_DISPI_INDEX_BANK depending on the current access mode.
   Which is probably effective in stopping misprogramming by accident.
   But from a security point of view completely useless as an attacker
   can easily change access modes after setting the bank register.
   Drop the bogus check, add range checks to vga_mem_{readb,writeb}
   instead.
   Fixes: CVE-2016-3710
   Reported-by: Qinghao Tang <luodalongde at gmail.com>
   Signed-off-by: Gerd Hoffmann <kraxel at redhat.com>
   [Backport to qemu-xen-tradition]
   Signed-off-by: Andrew Cooper <andrew.cooper3 at citrix.com>
   Upstream commit bebb4f580901fb638016d9851a28dbb83d44b3a6
   Backported-by: Zhenzhong Duan <zhenzhong.duan at oracle.com>
   Reviewed-by: Boris Ostrovsky <boris.ostrovsky at oracle.com> [bug 
23263192] {CVE-2016-3710}

[4.1.3-25.el5.223.18]
- 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.17]
- 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}

[4.1.3-25.el5.223.16]
- x86/VMX: sanitize rIP before re-entering guest
   ... to prevent guest user mode arranging for a guest crash (due to
   failed VM entry). (On the AMD system I checked, hardware is doing
   exactly the canonicalization being added here.)
   Note that fixing this in an architecturally correct way would be quite
   a bit more involved: Making the x86 instruction emulator check all
   branch targets for validity, plus dealing with invalid rIP resulting
   from update_guest_eip() or incoming directly during a VM exit. The only
   way to get the latter right would be by not having hardware do the
   injection.
   Note further that there are a two early returns from
   vmx_vmexit_handler(): One (through vmx_failed_vmentry()) leads to
   domain_crash() anyway, and the other covers real mode only and can
   neither occur with a non-canonical rIP nor result in an altered rIP,
   so we don't need to force those paths through the checking logic.
   This is XSA-170.
   Reported-by: liuling-it <liuling-it at 360.cn>
   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>
   Acked-by: Chuck Anderson <chuck.anderson at oracle.com> [bug 23128538] 
{CVE-2015-5307}

[4.1.3-25.el5.223.15]
- xenfb: avoid reading twice the same fields from the shared page
   Reading twice the same field could give the guest an attack of
   opportunity. In the case of event->type, gcc could compile the switch
   statement into a jump table, effectively ending up reading the type
   field multiple times.
   This is part of XSA-155.
   Signed-off-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>
   Upsteam commit 0ffd4547665d2fec648ab2c9ff856c5d9db9b07c
   Backported-by: Zhenzhong Duan <zhenzhong.duan at oracle.com> [bug 
23170509] {CVE-2015-8550}

[4.1.3-25.el5.223.14]
- blkif: Avoid double access to src->nr_segments
   src is stored in shared memory and src->nr_segments is dereferenced
   twice at the end of the function.  If a compiler decides to compile this
   into two separate memory accesses then the size limitation could be
   bypassed.
   Fix it by removing the double access to src->nr_segments.
   This is part of XSA-155.
   Signed-off-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>
   Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com>
   Upsteam commit 27942b0cb2327e93deb12326bbe7b36c81f9fa7b
   Backported-by: Zhenzhong Duan <zhenzhong.duan at oracle.com>
   Acked-by: Chuck Anderson <chuck.anderson at oracle.com> [bug 23170509] 
{CVE-2015-8550}

[4.1.3-25.el5.223.13]
- blktap2: Use RING_COPY_REQUEST
   Instead of RING_GET_REQUEST. Using a local copy of the
   ring (and also with proper memory barriers) will mean
   we can do not have to worry about the compiler optimizing
   the code and doing a double-fetch in the shared memory space.
   This is part of XSA155.
   Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com>
   ---
   v2: Fix compile issues with tapdisk-vbd
   Upsteam commit 851ffb4eea917e2708c912291dea4d133026c0ac
   Backported-by: Zhenzhong Duan <zhenzhong.duan at oracle.com>
   Acked-by: Chuck Anderson <chuck.anderson at oracle.com> [bug 23170509] 
{CVE-2015-8550}

[4.1.3-25.el5.223.12]
- xen: Add RING_COPY_REQUEST()
   Using RING_GET_REQUEST() on a shared ring is easy to use incorrectly
   (i.e., by not considering that the other end may alter the data in the
   shared ring while it is being inspected).  Safe usage of a request
   generally requires taking a local copy.
   Provide a RING_COPY_REQUEST() macro to use instead of
   RING_GET_REQUEST() and an open-coded memcpy().  This takes care of
   ensuring that the copy is done correctly regardless of any possible
   compiler optimizations.
   Use a volatile source to prevent the compiler from reordering or
   omitting the copy.
   This is part of XSA155.
   Signed-off-by: David Vrabel <david.vrabel at citrix.com>
   Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com>
   ---
   v2: Add comment about GCC bug.
   Upsteam commit 12b11658a9d6a654a1e7acbf2f2d56ce9a396c86
   Backported-by: Zhenzhong Duan <zhenzhong.duan at oracle.com>
   Reviewed-by: Chuck Anderson <chuck.anderson at oracle.com> [bug 
23170509] {CVE-2015-8550}

[4.1.3-25.el5.223.11]
- x86: don't leak ST(n)/XMMn values to domains first using them
   FNINIT doesn't alter these registers, and hence using it is
   insufficient to initialize a guest's initial state.
   This is XSA-165.
   Signed-off-by: Jan Beulich <jbeulich at suse.com>
   Reviewed-by: Andrew Cooper <andrew.cooper3 at citrix.com>
   [Backported to Xen 4.1.x]
   Signed-off-by: Stefan Bader <stefan.bader at canonical.com>
   Stefan Bader's backport of XSA-165 for Xen 4.1
   Backported-by: Zhenzhong Duan <zhenzhong.duan at oracle.com>
   Acked-by: Chuck Anderson <chuck.anderson at oracle.com> [bug 23128446] 
{CVE-2015-8555}

[4.1.3-25.el5.223.10]
- vmx: restore debug registers when injecting #DB traps
   Commit a929bee0e652 ("x86/vmx: Fix injection of #DB traps following
   XSA-156") prevents an infinite loop in certain #DB traps. However, it
   changed the behavior to not call hvm_hw_inject_trap() for #DB and #AC
   traps which which means that the debug registers are not restored
   correctly and nullified commit b56ae5b48c38 ("VMX: fix/adjust trap
   injection").
   To fix this, restore the original code path through hvm_inject_trap(),
   but ensure that the struct hvm_trap is populated with all the required
   data.
   Signed-off-by: Ross Lagerwall <ross.lagerwall at citrix.com>
   Reviewed-by: Jan Beulich <jbeulich at suse.com>
   Acked-by: Kevin Tian <kevin.tian at intel.com>
   Conflicts:
   xen/arch/x86/hvm/vmx/vmx.c
   Upstream commit ba22f1f4732acb4d5aebd779122e91753a0e374d
   Backported-by: Zhenzhong Duan <zhenzhong.duan at oracle.com>
   Reviewed-by: Chuck Anderson <chuck.anderson at oracle.com> [bug 
23128266] {CVE-2015-5307}

[4.1.3-25.el5.223.9]
- x86/vmx: Fix injection of #DB traps following XSA-156
   Most #DB exceptions are traps rather than faults, meaning that the 
instruction
   pointer in the exception frame points after the instruction rather 
than at it.
   However, VMX intercepts all have fault semantics, even when 
intercepting a
   trap.  Re-injecting an intercepted trap as a fault causes an infinite 
loop in
   the guest, by re-executing the same trapping instruction repeatedly. 
  This
   breaks debugging inside the guest.
   Introduce a helper which copies VM_EXIT_INTR_INTO to 
VM_ENTRY_INTR_INFO, and
   use it to mirror the intercepted interrupt back to the guest.
   Signed-off-by: Andrew Cooper <andrew.cooper3 at citrix.com>
   Acked-by: Kevin Tian <kevin.tian at intel.com>
   master commit: 0747bc8b4d85f3fc0ee1e58418418fa0229e8ff8
   master date: 2016-01-05 11:28:56 +0000
   Conflicts:
   xen/arch/x86/hvm/vmx/vmx.c
   Upstream commit a929bee0e65296ee565251316dc53f1c6b79084a
   Backported-by: Zhenzhong Duan <zhenzhong.duan at oracle.com>
   Reviewed-by: Chuck Anderson <chuck.anderson at oracle.com> [bug 
23128266] {CVE-2015-5307}

[4.1.3-25.el5.223.8]
- x86/HVM: always intercept #AC and #DB
   Both being benign exceptions, and both being possible to get triggered
   by exception delivery, this is required to prevent a guest from locking
   up a CPU (resulting from no other VM exits occurring once getting into
   such a loop).
   The specific scenarios:
   1) #AC may be raised during exception delivery if the handler is set to
   be a ring-3 one by a 32-bit guest, and the stack is misaligned.
   2) #DB may be raised during exception delivery when a breakpoint got
   placed on a data structure involved in delivering the exception. This
   can result in an endless loop when a 64-bit guest uses a non-zero IST
   for the vector 1 IDT entry, but even without use of IST the time it
   takes until a contributory fault would get raised (results depending
   on the handler) may be quite long.
   This is XSA-156.
   Reported-by: Benjamin Serebrin <serebrin at google.com>
   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>
   Conflicts:
   xen/arch/x86/hvm/svm/svm.c
   xen/arch/x86/hvm/vmx/vmx.c
   Backported-by: Zhenzhong Duan <zhenzhong.duan at oracle.com>
   Reviewed-by: Chuck Anderson <chuck.anderson at oracle.com> [bug 
23128266] {CVE-2015-5307}

[4.1.3-25.el5.223.7]
- x86/hvm/vmx: Trace traps and realmode exits
   Add some more tracing to vmexits that don't currently have
   trace information:
   * VMX realmode emulation
   * Various VMX traps
   * Fast-pathed APIC accesses
   Signed-off-by: George Dunlap <george.dunlap at eu.citrix.com>
   Committed-by: Keir Fraser <keir at xen.org>
   Upstream commit a2a88004afe1cce99bba724929d59366e752e886
   Backported-by: Zhenzhong Duan <zhenzhong.duan at oracle.com> [bug 
23128266] {CVE-2015-5307}

[4.1.3-25.el5.223.6]
- x86: fix unintended fallthrough case from XSA-154
   ... and annotate the other deliberate one: Coverity objects otherwise.
   Signed-off-by: Andrew Cooper <andrew.cooper3 at citrix.com>
   One of the two instances was actually a bug.
   Signed-off-by: Jan Beulich <jbeulich at suse.com>
   master commit: 8dd6d1c099865ee5f5916616a0ca79cd943c46f9
   master date: 2016-02-18 15:10:07 +0100
   Conflicts:
   xen/arch/x86/mm.c
   Upstream commit ccc7adf9cff5d5f93720afcc1d0f7227d50feab2
   Backported-by: Zhenzhong Duan <zhenzhong.duan at oracle.com>
   Reviewed-by: Boris Ostrovsky <boris.ostrovsky at oracle.com>
   Reviewed-by: Chuck Anderson <chuck.anderson at oracle.com> [bug 
23128198] {CVE-2016-2270}

[4.1.3-25.el5.223.5]
- x86: enforce consistent cachability of MMIO mappings
   We've been told by Intel that inconsistent cachability between
   multiple mappings of the same page can affect system stability only
   when the affected page is an MMIO one. Since the stale data issue is
   of no relevance to the hypervisor (since all guest memory accesses go
   through proper accessors and validation), handling of RAM pages
   remains unchanged here. Any MMIO mapped by domains however needs to be
   done consistently (all cachable mappings or all uncachable ones), in
   order to avoid Machine Check exceptions. Since converting existing
   cachable mappings to uncachable (at the time an uncachable mapping
   gets established) would in the PV case require tracking all mappings,
   allow MMIO to only get mapped uncachable (UC, UC-, or WC).
   This also implies that in the PV case we mustn't use the L1 PTE update
   fast path when cachability flags get altered.
   Since in the HVM case at least for now we want to continue honoring
   pinned cachability attributes for pages not mapped by the hypervisor,
   special case handling of r/o MMIO pages (forcing UC) gets added there.
   Arguably the counterpart change to p2m-pt.c may not be necessary, since
   UC- (which already gets enforced there) is probably strict enough.
   Note that the shadow code changes include fixing the write protection
   of r/o MMIO ranges: shadow_l1e_remove_flags() and its siblings, other
   than l1e_remove_flags() and alike, return the new PTE (and hence
   ignoring their return values makes them no-ops).
   This is CVE-2016-2270 / XSA-154.
   Signed-off-by: Jan Beulich <jbeulich at suse.com>
   Acked-by: Andrew Cooper <andrew.cooper3 at citrix.com>
   Conflicts:
   docs/misc/xen-command-line.markdown
   xen/arch/x86/mm/p2m-pt.c
   xen/arch/x86/mm/shadow/multi.c
   xen/arch/x86/mm.c
   Backported-by: Zhenzhong Duan <zhenzhong.duan at oracle.com>
   Reviewed-by: Boris Ostrovsky <boris.ostrovsky at oracle.com>
   Reviewed-by: Chuck Anderson <chuck.anderson at oracle.com> [bug 
23128198] {CVE-2016-2270}

[4.1.3-25.el5.223.4]
- x86/mm: fix mod_l1_entry() return value when encountering r/o MMIO page
   While putting together the workaround announced in
   http://lists.xen.org/archives/html/xen-devel/2012-06/msg00709.html, I
   found that mod_l1_entry(), upon encountering a set bit in
   mmio_ro_ranges, would return 1 instead of 0 (the removal of the write
   permission is supposed to be entirely transparent to the caller, even
   more so to the calling guest).
   Signed-off-by: Jan Beulich <jbeulich at suse.com>
   Acked-by: Keir Fraser <keir at xen.org>
   Upstream commit 70622118ee7bb925205c5d8c1e7bec82fc257351
   Backported-by: Zhenzhong Duan <zhenzhong.duan at oracle.com>
   Reviewed-by: Boris Ostrovsky <boris.ostrovsky at oracle.com>
   Reviewed-by: Chuck Anderson <chuck.anderson at oracle.com> [bug 
23128198] {CVE-2016-2270}

[4.1.3-25.el5.223.3]
- x86: make mod_l2_entry() return a proper error code
   ... so that finally all mod_lN_entry() functions behave identically,
   allowing some cleanup in do_mmu_update() (which no longer needs to
   track both an okay status and an error code).
   Signed-off-by: Jan Beulich <jbeulich at novell.com>
   Conflicts:
   xen/arch/x86/mm.c
   Upstream commit 7f107ea5c0790f6a702c801589d13bd275e20260
   Backported-by: Zhenzhong Duan <zhenzhong.duan at oracle.com>
   Reviewed-by: Boris Ostrovsky <boris.ostrovsky at oracle.com>
   Reviewed-by: Chuck Anderson <chuck.anderson at oracle.com> [bug 
23128198] {CVE-2016-2270}

[4.1.3-25.el5.223.2]
- x86: make mod_l1_entry() return a proper error code
   ... again is so that the guest can actually know the reason for the
   (hypercall) failure.
   Signed-off-by: Jan Beulich <jbeulich at novell.com>
   Upstream commit 541ce4766e7a3d1c3e36b70ff75f8b900ad8d20f
   Backported-by: Zhenzhong Duan <zhenzhong.duan at oracle.com>
   Reviewed-by: Boris Ostrovsky <boris.ostrovsky at oracle.com>
   Reviewed-by: Chuck Anderson <chuck.anderson at oracle.com> [bug 
23128198] {CVE-2016-2270}

[4.1.3-25.el5.223.1]
- x86: make get_page_from_l1e() return a proper error code
   ... so that the guest can actually know the reason for the (hypercall)
   failure.
   ptwr_do_page_fault() could propagate the error indicator received from
   get_page_from_l1e() back to the guest in the high half of the error
   code (entry_vector), provided we're sure all existing guests can deal
   with that (or indicate so by means of a to-be-added guest feature
   flag). Alternatively, a second virtual status register (like CR2)
   could be introduced.
   Signed-off-by: Jan Beulich <jbeulich at novell.com>
   Upstream commit be640b1800bbaaadf4db81b3badbb38714c2f309
   Backported-by: Zhenzhong Duan <zhenzhong.duan at oracle.com>
   Reviewed-by: Boris Ostrovsky <boris.ostrovsky at oracle.com>
   Reviewed-by: Chuck Anderson <chuck.anderson at oracle.com> [bug 
23128198] {CVE-2016-2270}

[4.1.3-25.el5.223]
- x86: fix information leak on AMD CPUs
   The fix for XSA-52 was wrong, and so was the change synchronizing that
   new behavior to the FXRSTOR logic: AMD's manuals explictly state that
   writes to the ES bit are ignored, and it instead gets calculated from
   the exception and mask bits (it gets set whenever there is an unmasked
   exception, and cleared otherwise). Hence we need to follow that model
   in our workaround.
   This is XSA-172 / CVE-2016-3158.
   Signed-off-by: Jan Beulich <jbeulich at suse.com>
   Reviewed-by: Andrew Cooper <andrew.cooper3 at citrix.com>
   Based on xen.org's xsa172-4.3.patch
   Conflicts:
   xrstor() is in xen/arch/x86/i387.c
   slightly different base code.
   Signed-off-by: Chuck Anderson <chuck.anderson at oracle.com>
   Reviewed-by: Boris Ostrovsky <boris.ostrovsky at oracle.com>
   Tested-by: Boris Ostrovsky <boris.ostrovsky at oracle.com> [bug 
23006903] {CVE-2016-3158,CVE-2016-3159}

[4.1.3-25.el5.222]
- xen: enable vcpu migration during system suspend
   Xen doesn't do vcpu migration when it prepare to disable all non boot 
cpus.
   This does work in most cases, but we could reproduce a page fault 
with below
   cmd:
     (XEN) Xen call trace:
   (XEN)    [<ffff82c48011f5d6>] vcpu_wake+0x46/0x3e0
   (XEN)    [<ffff82c48015e4ba>] do_IRQ+0x27a/0x5d0
   (XEN)    [<ffff82c48014ff6d>] vcpu_kick+0x1d/0x80
   (XEN)    [<ffff82c48014c5ea>] __find_next_bit+0x6a/0x70
   (XEN)    [<ffff82c480105dab>] evtchn_set_pending+0xab/0x1b0
   (XEN)    [<ffff82c4801060e6>] send_guest_vcpu_virq+0x46/0x70
   (XEN)    [<ffff82c48011de00>] vcpu_singleshot_timer_fn+0x0/0x10
   (XEN)    [<ffff82c48012393c>] execute_timer+0x4c/0x70
   (XEN)    [<ffff82c480123de5>] timer_softirq_action+0x85/0x220
   (XEN)    [<ffff82c4801214a5>] __do_softirq+0x65/0x90
   (XEN)    [<ffff82c480173d6e>] __cpu_die+0x4e/0xa0
   (XEN)    [<ffff82c48010106f>] cpu_down+0xdf/0x150
   (XEN)    [<ffff82c480148f0e>] acpi_get_table+0x5e/0xb0
   (XEN)    [<ffff82c4801012ae>] disable_nonboot_cpus+0x9e/0x140
   (XEN)    [<ffff82c4801945fb>] enter_state_helper+0xcb/0x350
   (XEN)    [<ffff82c480104959>] 
continue_hypercall_tasklet_handler+0xe9/0x100
   (XEN)    [<ffff82c48012329e>] do_tasklet_work+0x5e/0xb0
   (XEN)    [<ffff82c48012336e>] do_tasklet+0x7e/0xc0
   (XEN)    [<ffff82c480150af9>] idle_loop+0x19/0x60
   If vcpu isn't migrated when vcpu->processor is down, vcpu->processor 
keeps a
   stale value. All the structures allocated for vcpu->processor are already
   freed, access to these structures lead to page fault.
   In above trace, per_cpu(schedule_data, v->processor).schedule_lock is 
accessed.
   Signed-off-by: Zhenzhong Duan <zhenzhong.duan at oracle.com>
   Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com> [bug 
22753848]

[4.1.3-25.el5.221]
- xend: error out if pcnet emulated driver model is used.
   From http://xenbits.xen.org/xsa/advisory-162.html:
   The QEMU security team has predisclosed the following advisory:
   The AMD PC-Net II emulator(hw/net/pcnet.c), while receiving
   packets in loopback mode, appends CRC code to the receive
   buffer. If the data size given is same as the buffer size(4096),
   the appended CRC code overwrites 4 bytes after the s->buffer,
   making the adjacent 's->irq' object point to a new location.
   IMPACT
   ======
   A guest which has access to an emulated PCNET network device
   (e.g. with "model=pcnet" in their VIF configuration) can exploit this
   vulnerability to take over the qemu process elevating its privilege to
   that of the qemu process.
   This patch resolves XSA-162 but is not the solution provided by xen.org.
   Fail the creation if model=pcnet is used.
   Suggested-by:  Boris Ostrovsky <boris.ostrovsky at oracle.com>
   Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com>
   Acked-by: Chuck Anderson <chuck.anderson at oracle.com> [bug 22591625] 
{CVE-2015-7504}

[4.1.3-25.el5.220]
- x86/HVM: avoid reading ioreq state more than once
   Otherwise, especially when the compiler chooses to translate the
   switch() to a jump table, unpredictable behavior (and in the jump table
   case arbitrary code execution) can result.
   This is XSA-166.
   Signed-off-by: Jan Beulich <jbeulich at suse.com>
   Acked-by: Ian Campbell <ian.campbell at citrix.com>
   Acked-by: Chuck Anderson <chuck.anderson at oracle.com> [bug 22593156]

[4.1.3-25.el5.219]
- MSI-X: avoid array overrun upon MSI-X table writes
   pt_msix_init() allocates msix->msix_entry[] to just cover
   msix->total_entries entries. While pci_msix_readl() resorts to reading
   physical memory for out of bounds reads, pci_msix_writel() so far
   simply accessed/corrupted unrelated memory.
   pt_iomem_map()'s call to cpu_register_physical_memory() registers a
   page granular region, which is necessary as the Pending Bit Array may
   share space with the MSI-X table (but nothing else is allowed to). This
   also explains why pci_msix_readl() actually honors out of bounds reads,
   but pci_msi_writel() doesn't need to.
   This is XSA-164.
   Signed-off-by: Jan Beulich <jbeulich at suse.com>
   Acked-by: Ian Campbell <ian.campbell at citrix.com>
   Acked-by: Chuck Anderson <chuck.anderson at oracle.com> [bug 22588869] 
{CVE-2015-8554}

[4.1.3-25.el5.218]
- VT-d: fix TLB flushing in dma_pte_clear_one()
   From: Jan Beulich <jbeulich at suse.com>
   The TLB flush code was wrong since xen-4.1.3-25.el5.127.20 (commit:
   vtd-Refactor-iotlb-flush-code.patch), both ovm-3.2.9 and ovm-3.2.10 were
   affected.
   The third parameter of __intel_iommu_iotlb_flush() is to indicate
   whether the to be flushed entry was a present one. A few lines before,
   we bailed if !dma_pte_present(*pte), so there's no need to check the
   flag here again - we can simply always pass TRUE here.
   This is CVE-2013-6375 / XSA-78.
   Suggested-by: Cheng Yueqiang <yqcheng.2008 at phdis.smu.edu.sg>
   Signed-off-by: Jan Beulich <jbeulich at suse.com>
   Reviewed-by: Andrew Cooper <andrew.cooper3 at citrix.com>
   Acked-by: Keir Fraser <keir at xen.org>
   (cherry picked from commit 85c72f9fe764ed96f5c149efcdd69ab7c18bfe3d)
   Signed-off-by: Bob Liu <bob.liu at oracle.com>
   Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com>
   Acked-by: Chuck Anderson <chuck.anderson at oracle.com> [bug 22026725] 
{CVE-2013-6375}

[4.1.3-25.el5.217]
- x86/VMX: prevent INVVPID failure due to non-canonical guest address
   While INVLPG (and on SVM INVLPGA) don't fault on non-canonical
   addresses, INVVPID fails (in the "individual address" case) when passed
   such an address.
   Since such intercepted INVLPG are effectively no-ops anyway, don't fix
   this in vmx_invlpg_intercept(), but instead have paging_invlpg() never
   return true in such a case.
   This is XSA-168.
   Signed-off-by: Jan Beulich <jbeulich at suse.com>
   Reviewed-by: Andrew Cooper <andrew.cooper3 at citrix.com>
   Acked-by: Ian Campbell <ian.campbell at citrix.com>
   Acked-by: Chuck Anderson <chuck.anderson at oracle.com> [bug 22584930] 
{CVE-2016-1571}

[4.1.3-25.el5.216]
- x86/mm: PV superpage handling lacks sanity checks
   MMUEXT_{,UN}MARK_SUPER fail to check the input MFN for validity before
   dereferencing pointers into the superpage frame table.
   get_superpage() has a similar issue.
   This is XSA-167.
   Reported-by: Qinghao Tang <luodalongde at gmail.com>
   Signed-off-by: Jan Beulich <jbeulich at suse.com>
   Acked-by: Ian Campbell <ian.campbell at citrix.com>
   Acked-by: Chuck Anderson <chuck.anderson at oracle.com> [bug 22584929] 
{CVE-2016-1570}

[4.1.3-25.el5.215]
- xend/image: Don't throw VMException when using backend domains for disks.
   If we are using backend domains the disk image may not be
   accessible within the host (domain0). As such it is OK to
   continue on.
   The 'addStoreEntries' in DevController.py already does the check
   to make sure that when the 'backend' configuration is used - that
   said domain exists.
   As such the only change we need to do is to exclude the disk
   image location if the domain is not dom0.
   Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com>
   Acked-by: Adnan Misherfi <adnan.misherfi at oracle.com>
   Signed-off-by: Zhigang Wang <zhigang.x.wang at oracle.com>
   Signed-off-by: Joe Jin <joe.jin at oracle.com> [bug 22242536]

[4.1.3-25.el5.214]
- memory: fix XENMEM_exchange error handling
   assign_pages() can fail due to the domain getting killed in parallel,
   which should not result in a hypervisor crash.
   Also delete a redundant put_gfn() - all relevant paths leading to the
   "fail" label already do this (and there are also paths where it was
   plain wrong). All of the put_gfn()-s got introduced by 51032ca058
   ("Modify naming of queries into the p2m"), including the otherwise
   unneeded initializer for k (with even a kind of misleading comment -
   the compiler warning could actually have served as a hint that the use
   is wrong).
   This is XSA-159.
   Signed-off-by: Jan Beulich <jbeulich at suse.com>
   Acked-by: Ian Campbell <ian.campbell at citrix.com>
   Based on xen.org's xsa159.patch
   Conflicts:
   OVM 3.2 does not have the change (51032ca058) that is backed out
   in xen/common/memory.c or the put_gfn() in xen/common/memory.c
   Acked-by: Chuck Anderson <chuck.anderson at oracle.com>
   Reviewed-by: John Haxby <john.haxby at oracle.com> [bug 22326044] 
{CVE-2015-8339,CVE-2015-8340}

[4.1.3-25.el5.213]
- x86: rate-limit logging in do_xen{oprof,pmu}_op()
   Some of the sub-ops are acessible to all guests, and hence should be
   rate-limited. In the xenoprof case, just like for XSA-146, include them
   only in debug builds. Since the vPMU code is rather new, allow them to
   be always present, but downgrade them to (rate limited) guest messages.
   This is XSA-152.
   Signed-off-by: Jan Beulich <jbeulich at suse.com>
   Acked-by: Chuck Anderson <chuck.anderson at oracle.com>
   Reviewed-by: John Haxby <john.haxby at oracle.com> [bug 22088906] 
{CVE-2015-7971}

[4.1.3-25.el5.212]
- xenoprof: free domain's vcpu array
   This was overlooked in fb442e2171 ("x86_64: allow more vCPU-s per
   guest").
   This is XSA-151.
   Signed-off-by: Jan Beulich <jbeulich at suse.com>
   Reviewed-by: Ian Campbell <ian.campbell at citrix.com>
   Acked-by: Chuck Anderson <chuck.anderson at oracle.com>
   Reviewed-by: John Haxby <john.haxby at oracle.com> [bug 22088836] 
{CVE-2015-7969}

[4.1.3-25.el5.211]
- x86: guard against undue super page PTE creation
   When optional super page support got added (commit bd1cd81d64 "x86: PV
   support for hugepages"), two adjustments were missed: mod_l2_entry()
   needs to consider the PSE and RW bits when deciding whether to use the
   fast path, and the PSE bit must not be removed from L2_DISALLOW_MASK
   unconditionally.
   This is XSA-148.
   Signed-off-by: Jan Beulich <jbeulich at suse.com>
   Reviewed-by: Tim Deegan <tim at xen.org>
   [backport to Xen 4.1]
   Signed-off-by: Andrew Cooper <andrew.cooper3 at citrix.com>
   Acked-by: Chuck Anderson <chuck.anderson at oracle.com>
   Reviewed-by: John Haxby <john.haxby at oracle.com> [bug 22088411] 
{CVE-2015-7835}

[4.1.3-25.el5.210]
- chkconfig services should associated with xen-tools
   Signed-off-by: Zhigang Wang <zhigang.x.wang at oracle.com>
   Reviewed-by: Adnan Misherfi <adnan.misherfi at oracle.com> [bug 21889174]



More information about the Oraclevm-errata mailing list