OracleVM 3.3 : xen (OVMSA-2016-0007)

High Nessus Plugin ID 88170


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


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

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

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


Update the affected xen / xen-tools packages.

See Also

Plugin Details

Severity: High

ID: 88170

File Name: oraclevm_OVMSA-2016-0007.nasl

Version: $Revision: 2.5 $

Type: local

Published: 2016/01/26

Modified: 2017/02/14

Dependencies: 12634

Risk Information

Risk Factor: High


Base Score: 7.8

Temporal Score: 5.8

Vector: CVSS2#AV:N/AC:L/Au:N/C:N/I:N/A:C

Temporal Vector: CVSS2#E:U/RL:OF/RC:C


Base Score: 8.6

Temporal Score: 7.5

Vector: CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N

Temporal Vector: CVSS:3.0/E:U/RL:O/RC:C

Vulnerability Information

CPE: p-cpe:/a:oracle:vm:xen, p-cpe:/a:oracle:vm:xen-tools, cpe:/o:oracle:vm_server:3.3

Required KB Items: Host/local_checks_enabled, Host/OracleVM/release, Host/OracleVM/rpm-list

Exploit Available: false

Exploit Ease: No known exploits are available

Patch Publication Date: 2016/01/25

Reference Information

CVE: CVE-2015-5307, CVE-2015-8104, CVE-2015-8339, CVE-2015-8340, CVE-2015-8341, CVE-2015-8554, CVE-2015-8555, CVE-2016-1570, CVE-2016-1571

OSVDB: 130089, 130090, 131284, 131285, 131453, 132032, 132050, 133503, 133504