OracleVM 3.2 : xen (OVMSA-2013-0085)

Medium Nessus Plugin ID 79523


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/HVM: only allow ring 0 guest code to make hypercalls Anything else would allow for privilege escalation. This is CVE-2013-4554 / XSA-76. (CVE-2013-4554)

- x86: restrict XEN_DOMCTL_getmemlist Coverity ID 1055652 (See the code comment.) This is CVE-2013-4553 / XSA-74.

- gnttab: update version 1 of xsa73-4.1.patch to version 3 Version 1 of xsa73-4.1.patch had an error: bool_t drop_dom_ref = (e->tot_pages-- == 0) should have been:
bool_t drop_dom_ref = (e->tot_pages-- == 1)

Consolidate error handling.

Backported to Xen-4.1 (CVE-2013-4494)

- Xen: Spread boot time page scrubbing across all available CPU's Written by Malcolm Crossley The page scrubbing is done in 256MB chunks in lockstep across all the CPU's. This allows for the boot CPU to hold the heap_lock whilst each chunk is being scrubbed and then release the heap_lock when all CPU's are finished scrubing their individual chunk. This allows for the heap_lock to not be held continously and for pending softirqs are to be serviced periodically across all CPU's. The page scrub memory chunks are allocated to the CPU's in a NUMA aware fashion to reduce Socket interconnect overhead and improve performance. This patch reduces the boot page scrub time on a 256GB 16 core AMD Opteron machine from 1 minute 46 seconds to 38 seconds.

- gnttab: correct locking order reversal Coverity ID 1087189 Correct a lock order reversal between a domains page allocation and grant table locks. This is XSA-73.

Consolidate error handling.

Backported to Xen-4.1 (CVE-2013-4494)

- piix4acpi, xen, hotplug: Fix race with ACPI AML code and hotplug. This is a race so the amount varies but on a 4PCPU box I seem to get only ~14 out of 16 vCPUs I want to online. The issue at hand is that QEMU xenstore.c hotplug code changes the vCPU array and triggers an ACPI SCI for each vCPU online/offline change. That means we modify the array of vCPUs as the guests ACPI AML code is reading it - resulting in the guest reading the data only once and not changing the CPU states appropiately.
The fix is to seperate the vCPU array changes from the ACPI SCI notification. The code now will enumerate all of the vCPUs and change the vCPU array if there is a need for a change. If a change did occur then only _one_ ACPI SCI pulse is sent to the guest. The vCPU array at that point has the online/offline modified to what the user wanted to have.

[v1: Use stack for the 'attr' instead of malloc/free]

- piix4acpi, xen: Clarify that the qemu_set_irq calls just do an IRQ pulse. The 'qemu_cpu_notify' raises and lowers the ACPI SCI line when the vCPU state has changed.
Instead of doing the two functions, just use one function that describes exactly what it does.

- piix4acpi, xen, vcpu hotplug: Split the notification from the changes. This is a prepatory patch that splits the notification of an vCPU change from the actual changes to the vCPU array.

- Backported Carson's changes - Requests to connect on port 8003 with a LOW/weak cipher are now rejected.


Update the affected xen / xen-devel / xen-tools packages.

See Also

Plugin Details

Severity: Medium

ID: 79523

File Name: oraclevm_OVMSA-2013-0085.nasl

Version: $Revision: 1.3 $

Type: local

Published: 2014/11/26

Modified: 2017/02/14

Dependencies: 12634

Risk Information

Risk Factor: Medium


Base Score: 5.2

Temporal Score: 4.5

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

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

Vulnerability Information

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

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: 2013/12/06

Reference Information

CVE: CVE-2013-4494, CVE-2013-4553, CVE-2013-4554

BID: 63494, 63931, 63933