- Home
- CVEs with nessus.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)
Max CVSS | 0 |
Min CVSS | 0 |
Total Count | 2 |
| ID | CVSS | Summary | Last (major) update | Published |
Back to Top
Mark selected
Back to Top