OracleVM 3.3 : xen (OVMSA-2016-0007)

high Nessus Plugin ID 88170

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 xen.org'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)

Solution

Update the affected xen / xen-tools packages.

See Also

http://www.nessus.org/u?ca4defaf

Plugin Details

Severity: High

ID: 88170

File Name: oraclevm_OVMSA-2016-0007.nasl

Version: 2.8

Type: local

Published: 1/26/2016

Updated: 1/4/2021

Supported Sensors: Nessus

Risk Information

VPR

Risk Factor: Medium

Score: 6.5

CVSS v2

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

CVSS v3

Risk Factor: High

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 Ease: No known exploits are available

Patch Publication Date: 1/25/2016

Vulnerability Publication Date: 11/16/2015

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