[Oraclevm-errata] OVMSA-2017-0117 Important: Oracle VM 3.3 xen security update

Errata Announcements for Oracle VM oraclevm-errata at oss.oracle.com
Fri Jun 30 08:55:44 PDT 2017


Oracle VM Security Advisory OVMSA-2017-0117

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

x86_64:
xen-4.3.0-55.el6.186.38.x86_64.rpm
xen-tools-4.3.0-55.el6.186.38.x86_64.rpm


SRPMS:
http://oss.oracle.com/oraclevm/server/3.3/SRPMS-updates/xen-4.3.0-55.el6.186.38.src.rpm



Description of changes:

[4.3.0-55.el6.186.38]
- From 414d97feb2e28ed131da33546ea81a919c30e285 Mon Sep 17 00:00:00 2001
   From: Jan Beulich <jbeulich at suse.com>
   Date: Fri, 2 Jun 2017 15:51:58 +0100
   Subject: [PATCH 4/4] gnttab: __gnttab_unmap_common_complete() is
   all-or-nothing
   All failures have to be detected in __gnttab_unmap_common(), the
   completion function must not skip part of its processing. In particular
   the GNTMAP_device_map related putting of page references and adjustment
   of pin count must not occur if __gnttab_unmap_common() signaled an
   error. Furthermore the function must not make adjustments to global
   state (here: clearing GNTTAB_device_map) before all possibly failing
   operations have been performed.
   There's one exception for IOMMU related failures: As IOMMU manipulation
   occurs after GNTMAP_*_map have been cleared already, the related page
   reference and pin count adjustments need to be done nevertheless. A
   fundamental requirement for the correctness of this is that
   iommu_{,un}map_page() crash any affected DomU in case of failure.
   The version check appears to be pointless (or could perhaps be a
   BUG_ON() or ASSERT()), but for the moment also move it.
   This is part of XSA-224.
   Reported-by: Jan Beulich <jbeulich at suse.com>
   Signed-off-by: Jan Beulich <jbeulich at suse.com>
   Backported-by: Zhenzhong Duan <zhenzhong.duan at oracle.com>
   Reviewed-by: Boris Ostrovsky <boris.ostrovsky at oracle.com> [bug 26224357]

[4.3.0-55.el6.186.37]
- From 5fd4726857a913e90de95623dc385f8856465839 Mon Sep 17 00:00:00 2001
   From: George Dunlap <george.dunlap at citrix.com>
   Date: Fri, 2 Jun 2017 15:21:27 +0100
   Subject: [PATCH 3/4] gnttab: correct logic to get page references 
during map
   requests
   The rules for reference counting are somewhat complicated:
   * Each of GNTTAB_host_map and GNTTAB_device_map need their own
   reference count
   * If the mapping is writeable:
   - GNTTAB_host_map needs a type count under only some conditions
   - GNTTAB_device_map always needs a type count
   If the mapping succeeds, we need to keep all of these; if the mapping
   fails, we need to release whatever references we have acquired so far.
   Additionally, the code that does a lot of this calculation "inherits"
   a reference as part of the process of finding out who the owner is.
   Finally, if the grant is mapped as writeable (without the
   GNTMAP_readonly flag), but the hypervisor cannot grab a
   PGT_writeable_page type, the entire operation should fail.
   Unfortunately, the current code has several logic holes:
   * If a grant is mapped only GNTTAB_device_map, and with a writeable
   mapping, but in conditions where a *host* type count is not
   necessary, the code will fail to grab the necessary type count.
   * If a grant is mapped both GNTTAB_device_map and GNTTAB_host_map,
   with a writeable mapping, in conditions where the host type count is
   not necessary, *and* where the page cannot be changed to type
   PGT_writeable, the condition will not be detected.
   In both cases, this means that on success, the type count will be
   erroneously reduced when the grant is unmapped.  In the second case,
   the type count will be erroneously reduced on the failure path as
   well.  (In the first case the failure path logic has the same hole
   as the reference grabbing logic.)
   Additionally, the return value of get_page() is not checked; but this
   may fail even if the first get_page() succeeded due to a reference
   counting overflow.
   First of all, simplify the restoration logic by explicitly counting
   the reference and type references acquired.
   Consider each mapping type separately, explicitly marking the
   'incoming' reference as used so we know when we need to grab a second
   one.
   Finally, always check the return value of get_page[_type]() and go to
   the failure path if appropriate.
   This is part of XSA-224.
   Signed-off-by: George Dunlap <george.dunlap at citrix.com>
   Signed-off-by: Jan Beulich <jbeulich at suse.com>
   Backported-by: Zhenzhong Duan <zhenzhong.duan at oracle.com>
   Reviewed-by: Boris Ostrovsky <boris.ostrovsky at oracle.com> [bug 26224357]

[4.3.0-55.el6.186.36]
- From 52078b99abbc534a5bda6f7d8ab2b403711a9bcf Mon Sep 17 00:00:00 2001
   From: Jan Beulich <jbeulich at suse.com>
   Date: Fri, 2 Jun 2017 15:21:27 +0100
   Subject: [PATCH 2/4] gnttab: never create host mapping unless asked to
   We shouldn't create a host mapping unless asked to even in the case of
   mapping a granted MMIO page. In particular the mapping wouldn't be torn
   down when processing the matching unmap request.
   This is part of XSA-224.
   Signed-off-by: Jan Beulich <jbeulich at suse.com>
   Backported-by: Zhenzhong Duan <zhenzhong.duan at oracle.com>
   Reviewed-by: Boris Ostrovsky <boris.ostrovsky at oracle.com> [bug 26224357]

[4.3.0-55.el6.186.35]
- From 0aa6bc3bba0aeec067feed2a7378d285d7529684 Mon Sep 17 00:00:00 2001
   From: George Dunlap <george.dunlap at citrix.com>
   Date: Thu, 15 Jun 2017 16:24:02 +0100
   Subject: [PATCH 1/4] gnttab: Fix handling of dev_bus_addr during unmap
   If a grant has been mapped with the GNTTAB_device_map flag, calling
   grant_unmap_ref() with dev_bus_addr set to zero should cause the
   GNTTAB_device_map part of the mapping to be left alone.
   Unfortunately, at the moment, op->dev_bus_addr is implicitly checked
   before clearing the map and adjusting the pin count, but only the bits
   above 12; and it is not checked at all before dropping page
   references.  This means a guest can repeatedly make such a call to
   cause the reference count to drop to zero, causing the page to be
   freed and re-used, even though it's still mapped in its pagetables.
   To fix this, always check op->dev_bus_addr explicitly for being
   non-zero, as well as op->flag & GNTMAP_device_map, before doing
   operations on the device_map.
   While we're here, make the logic a bit cleaner:
   * Always initialize op->frame to zero and set it from act->frame, to 
reduce the
   chance of untrusted input being used
   * Explicitly check the full dev_bus_addr against act->frame <<
   PAGE_SHIFT, rather than ignoring the lower 12 bits
   This is part of XSA-224.
   Reported-by: Jan Beulich <jbeulich at suse.com>
   Signed-off-by: George Dunlap <george.dunlap at citrix.com>
   Signed-off-by: Jan Beulich <jbeulich at suse.com>
   Backported-by: Zhenzhong Duan <zhenzhong.duan at oracle.com>
   Reviewed-by: Boris Ostrovsky <boris.ostrovsky at oracle.com> [bug 26224357]

[4.3.0-55.el6.186.34]
- From: Jan Beulich <jbeulich at suse.com>
   Subject: guest_physmap_remove_page() needs its return value checked
   Callers, namely such subsequently freeing the page, must not blindly
   assume success - the function may namely fail when needing to shatter a
   super page, but there not being memory available for the then needed
   intermediate page table.
   As it happens, guest_remove_page() callers now also all check the
   return value.
   Furthermore a missed put_gfn() on an error path in gnttab_transfer() is
   also being taken care of.
   This is part of XSA-222.
   Signed-off-by: Jan Beulich <jbeulich at suse.com>
   Signed-off-by: Julien Grall <julien.grall at arm.com>
   Reviewed-by: Andrew Cooper <andrew.cooper3 at citrix.com>
   Conflict:
   xen/arch/arm/p2m.c
   xen/arch/x86/mm.c
   xen/include/asm-arm/p2m.h
   Backported-by: Zhenzhong Duan <zhenzhong.duan at oracle.com>
   Reviewed-by: Boris Ostrovsky <boris.ostrovsky at oracle.com> [bug 26202617]

[4.3.0-55.el6.186.33]
- From: Andrew Cooper <andrew.cooper3 at citrix.com>
   Subject: xen/memory: Fix return value handing of guest_remove_page()
   Despite the description in mm.h, guest_remove_page() previously 
returned 0 for
   paging errors.
   Switch guest_remove_page() to having regular 0/-error semantics, and 
propagate
   the return values from clear_mmio_p2m_entry() and 
mem_sharing_unshare_page()
   to the callers (although decrease_reservation() is the only caller which
   currently cares).
   This is part of XSA-222.
   Signed-off-by: Andrew Cooper <andrew.cooper3 at citrix.com>
   Reviewed-by: Jan Beulich <jbeulich at suse.com>
   Conflict:
   xen/common/memory.c
   Backported-by: Zhenzhong Duan <zhenzhong.duan at oracle.com>
   Reviewed-by: Boris Ostrovsky <boris.ostrovsky at oracle.com> [bug 26202617]

[4.3.0-55.el6.186.32]
- From 6926e40943eef0e0ef7acfc53cee819a41a41247 Mon Sep 17 00:00:00 2001
   From: Andrew Cooper <andrew.cooper3 at citrix.com>
   Date: Thu, 11 May 2017 14:47:00 +0100
   Subject: [PATCH] x86/shadow: Hold references for the duration of emulated
   writes
   The (misnamed) emulate_gva_to_mfn() function translates a linear 
address to an
   mfn, but releases its page reference before returning the mfn to its 
caller.
   sh_emulate_map_dest() uses the results of one or two translations to 
construct
   a virtual mapping to the underlying frames, completes an emulated
   write/cmpxchg, then unmaps the virtual mappings.
   The page references need holding until the mappings are unmapped, or the
   frames can change ownership before the writes occurs.
   This is XSA-219
   Signed-off-by: Andrew Cooper <andrew.cooper3 at citrix.com>
   Reviewed-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 26202185]

[4.3.0-55.el6.186.31]
- From 1b0cf99d046286c601a28af0ef7c1a17eb3eb2cb Mon Sep 17 00:00:00 2001
   From: Jan Beulich <jbeulich at suse.com>
   Date: Thu, 15 Jun 2017 12:05:29 +0100
   Subject: [PATCH 4/4] gnttab: correct maptrack table accesses
   In order to observe a consistent (limit,pointer-table) pair, the reader
   needs to either hold the maptrack lock (in line with documentation) or
   both sides need to order their accesses suitably. At the same time add
   read barriers to lockless readers.
   This is part of XSA-218.
   Signed-off-by: Jan Beulich <jbeulich at suse.com>
   Backported-by: Zhenzhong Duan <zhenzhong.duan at oracle.com>
   Reviewed-by: Boris Ostrovsky <boris.ostrovsky at oracle.com> [bug 26202032]

[4.3.0-55.el6.186.30]
- From d188b4bf7c6d17fae1a7d14867aaeb72f972d3ac Mon Sep 17 00:00:00 2001
   From: George Dunlap <george.dunlap at citrix.com>
   Date: Fri, 2 Jun 2017 12:40:04 +0100
   Subject: [PATCH 3/4] gnttab: Avoid potential double-put of maptrack entry
   Each grant mapping for a particular domain is tracked by an in-Xen
   "maptrack" entry.  This entry is is referenced by a "handle", which is
   given to the guest when it calls gnttab_map_grant_ref().
   There are two types of mapping a particular handle can refer to:
   GNTMAP_host_map and GNTMAP_device_map.  A given
   gnttab_unmap_grant_ref() call can remove either only one or both of
   these entries.  When a particular handle has no entries left, it must
   be freed.
   gnttab_unmap_grant_ref() loops through its grant unmap request list
   twice.  It first removes entries from any host pagetables and (if
   appropraite) iommus; then it does a single domain TLB flush; then it
   does the clean-up, including telling the granter that entries are no
   longer being used (if appropriate).
   At the moment, it's during the first pass that the maptrack flags are
   cleared, but the second pass that the maptrack entry is freed.
   Unfortunately this allows the following race, which results in a
   double-free:
   A: (pass 1) clear host_map
   B: (pass 1) clear device_map
   A: (pass 2) See that maptrack entry has no mappings, free it
   B: (pass 2) See that maptrack entry has no mappings, free it #
   Unfortunately, unlike the active entry pinning update, we can't simply
   move the maptrack flag changes to the second half, because the
   maptrack flags are used to determine if iommu entries need to be
   added: a domain's iommu must never have fewer permissions than the
   maptrack flags indicate, or a subsequent map_grant_ref() might fail to
   add the necessary iommu entries.
   Instead, free the maptrack entry in the first pass if there are no
   further mappings.
   This is part of XSA-218.
   Signed-off-by: George Dunlap <george.dunlap at citrix.com>
   Signed-off-by: Jan Beulich <jbeulich at suse.com>
   Conflict:
   xen/common/grant_table.c
   Backported-by: Zhenzhong Duan <zhenzhong.duan at oracle.com>
   Reviewed-by: Boris Ostrovsky <boris.ostrovsky at oracle.com> [bug 26202032]

[4.3.0-55.el6.186.29]
- From abbbccaa119bf8b05f0828bd9138104f08c4f8df Mon Sep 17 00:00:00 2001
   From: Jan Beulich <jbeulich at suse.com>
   Date: Fri, 2 Jun 2017 12:22:42 +0100
   Subject: [PATCH 2/4] gnttab: fix unmap pin accounting race
   Once all {writable} mappings of a grant entry have been unmapped, the
   hypervisor informs the guest that the grant entry has been released by
   clearing the _GTF_{reading,writing} usage flags in the guest's grant
   table as appropriate.
   Unfortunately, at the moment, the code that updates the accounting
   happens in a different critical section than the one which updates the
   usage flags; this means that under the right circumstances, there may be
   a window in time after the hypervisor reported the grant as being free
   during which the grant referee still had access to the page.
   Move the grant accounting code into the same critical section as the
   reporting code to make sure this kind of race can't happen.
   This is part of XSA-218.
   Signed-off-by: Jan Beulich <jbeulich at suse.com>
   Backported-by: Zhenzhong Duan <zhenzhong.duan at oracle.com>
   Reviewed-by: Boris Ostrovsky <boris.ostrovsky at oracle.com> [bug 26202032]

[4.3.0-55.el6.186.28]
- From 4ca403ecff82d3efdd838e08b258cb4dd3062c60 Mon Sep 17 00:00:00 2001
   From: Quan Xu <quan.xu at intel.com>
   Date: Fri, 2 Jun 2017 12:30:34 +0100
   Subject: [PATCH 1/4] IOMMU: handle IOMMU mapping and unmapping failures
   Treat IOMMU mapping and unmapping failures as a fatal to the DomU
   If IOMMU mapping and unmapping failed, crash the DomU and propagate
   the error up to the call trees.
   No spamming of the log can occur. For DomU, we avoid logging any
   message for already dying domains. For Dom0, that'll still be more
   verbose than we'd really like, but it at least wouldn't outright
   flood the console.
   Signed-off-by: Quan Xu <quan.xu at intel.com>
   Reviewed-by: Kevin Tian <kevin.tian at intel.com>
   Reviewed-by: Jan Beulich <jbeulich at suse.com>
   Conflict:
   xen/drivers/passthrough/iommu.c
   Backported-by: Zhenzhong Duan <zhenzhong.duan at oracle.com>
   Reviewed-by: Boris Ostrovsky <boris.ostrovsky at oracle.com> [bug 26202032]

[4.3.0-55.el6.186.27]
- From: Jan Beulich <jbeulich at suse.com>
   Subject: x86/mm: disallow page stealing from HVM domains
   The operation's success can't be controlled by the guest, as the device
   model may have an active mapping of the page. If we nevertheless
   permitted this operation, we'd have to add further TLB flushing to
   prevent scenarios like
   "Domains A (HVM), B (PV), C (PV); B->target==A
   Steps:
   1. B maps page X from A as writable
   2. B unmaps page X without a TLB flush
   3. A sends page X to C via GNTTABOP_transfer
   4. C maps page X as pagetable (potentially causing a TLB flush in C,
   but not in B)
   At this point, X would be mapped as a pagetable in C while being
   writable through a stale TLB entry in B."
   A similar scenario could be constructed for A using XENMEM_exchange and
   some arbitrary PV domain C then having this page allocated.
   This is XSA-217.
   Signed-off-by: Jan Beulich <jbeulich at suse.com>
   Acked-by: George Dunlap <george.dunlap at citrix.com>
   Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com>
   Backported-by: Zhenzhong Duan <zhenzhong.duan at oracle.com>
   Reviewed-by: Boris Ostrovsky <boris.ostrovsky at oracle.com> [bug 26201839]

[4.3.0-55.el6.186.26]
- From: Jan Beulich <jbeulich at suse.com>
   Subject: xen/disk: don't leak stack data via response ring
   Rather than constructing a local structure instance on the stack, fill
   the fields directly on the shared ring, just like other (Linux)
   backends do. Build on the fact that all response structure flavors are
   actually identical (the old code did make this assumption too).
   This is XSA-216.
   Signed-off-by: Jan Beulich <jbeulich at suse.com>
   Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com>
   Acked-by: Anthony PERARD <anthony.perard at citrix.com>
   hw/block/xen_disk.c moved to hw/xen_disk.c
   hw/block/xen_blkif.h moved to hw/xen_blkif.h
   Backported-by: Zhenzhong Duan <zhenzhong.duan at oracle.com>
   Reviewed-by: Boris Ostrovsky <boris.ostrovsky at oracle.com> [bug 26201333]

[4.3.0-55.el6.186.25]
- From c976437c7dba9c7444fb41df45468968aaa326ad Mon Sep 17 00:00:00 2001
   From: Zhenzhong Duan <zhenzhong.duan at oracle.com>
   Date: Wed, 7 May 2014 13:41:48 +0000
   Subject: [PATCH] qemu-xen: free all the pirqs for msi/msix when 
driver unload
   Pirqs are not freed when driver unload, then new pirqs are allocated when
   driver reload. This could exhaust pirqs if do it in a loop.
   This patch fixes the bug by freeing pirqs when ENABLE bit is cleared in
   msi/msix control reg.
   There is also other way of fixing it such as reuse pirqs between 
driver reload,
   but this way is better.
   Xen-devel: http://marc.info/?l=xen-devel&m=136800120304275&w=2
   Signed-off-by: Zhenzhong Duan <zhenzhong.duan at oracle.com>
   Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com>
   Signed-off-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com> 
[bug 16910937]




More information about the Oraclevm-errata mailing list