OracleVM 3.3 : xen (OVMSA-2016-0007)

This script is Copyright (C) 2016-2017 Tenable Network Security, Inc.

Synopsis :

The remote OracleVM host is missing one or more security updates.

Description :

The remote OracleVM system is missing necessary patches to address
critical security updates :

- 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. (CVE-2016-1571)

- 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. (CVE-2016-1570)

- 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.

- 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. (CVE-2015-8555)

- 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. (CVE-2015-8554)

- From 43a10fecd6f4a9d8adf9f5d85e3d5e7187e2d54a Mon Sep 17
00:00:00 2001 From: Ian Jackson Date: Wed, 18 Nov 2015
15:34:54 +0000 Subject: [PATCH] libxl: Fix
bootloader-related virtual memory leak on pv build
failure The bootloader may call
libxl__file_reference_map, which mmap's the pv_kernel
and pv_ramdisk into process memory. This was only
unmapped, however, on the success path of
libxl__build_pv. If there were a failure anywhere
between libxl_bootloader.c:parse_bootloader_result and
the end of libxl__build_pv, the calls to
libxl__file_reference_unmap would be skipped, leaking
the mapped virtual memory. Ideally this would be fixed
by adding the unmap calls to the destruction path for
libxl__domain_build_state. Unfortunately the lifetime of
the libxl__domain_build_state is opaque, and it doesn't
have a proper destruction path. But, the only thing in
it that isn't from the gc are these bootloader
references, and they are only ever set for one
libxl__domain_build_state, the one which is
libxl__domain_create_state.build_state. So we can clean
up in the exit path from libxl__domain_create_*, which
always comes through domcreate_complete. Remove the
now-redundant unmaps in libxl__build_pv's success path.
This is XSA-160.

Based on's xsa160.patch Conflicts: adjust patch
context to match OVM 3.3 code base (CVE-2015-8341)

- 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

22326022] (CVE-2015-8339, CVE-2015-8340)

- 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

(CVE-2015-5307, CVE-2015-8104)

See also :

Solution :

Update the affected xen / xen-tools packages.

Risk factor :

High / CVSS Base Score : 7.8
CVSS Temporal Score : 5.8
Public Exploit Available : false

Family: OracleVM Local Security Checks

Nessus Plugin ID: 88170 ()

Bugtraq ID:

CVE ID: CVE-2015-5307

Ready to Amp Up Your Nessus Experience?

Get Nessus Professional to scan unlimited IPs, run compliance checks & more

Buy Nessus Professional Now