[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