OracleVM 3.1 : xen (OVMSA-2013-0032)

This script is Copyright (C) 2014-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 :

- defer event channel bucket pointer store until after XSM
checks Otherwise a dangling pointer can be left, which
would cause subsequent memory corruption as soon as the
space got re-allocated for some other purpose. This is
CVE-2013-1920 / XSA-47.

- x86: fix various issues with handling guest IRQs

- properly revoke IRQ access in map_domain_pirq error path

- don't permit replacing an in use IRQ

- don't accept inputs in the GSI range for

- track IRQ access permission in host IRQ terms, not guest
IRQ ones (and with that, also disallow Dom0 access to
IRQ0) This is CVE-2013-1919 / XSA-46.

- x86: clear EFLAGS.NT in SYSENTER entry path ... as it
causes problems if we happen to exit back via IRET: In
the course of trying to handle the fault, the hypervisor
creates a stack course of trying to handle the fault,
the hypervisor creates a stack frame by hand, and uses
PUSHFQ to set the respective EFLAGS field, but expects
to be able to IRET through that stack frame to the
second portion of the fixup code (which causes a #GP due
to the stored EFLAGS having NT set). And even if this
worked (e.g if we cleared NT in that path), it would
then (through the fail safe callback) cause a #GP in the
guest with the SYSENTER handler's first instruction as
the source, which in turn would allow guest user mode
code to crash the guest kernel. Inject a #GP on the fake
(NULL) address of the SYSENTER instruction instead, just
like in the case where the guest kernel didn't register
a corresponding entry point. On 32-bit we also need to
make sure we clear SYSENTER_CS for all CPUs (neither
#RESET nor #INIT guarantee this). This is CVE-2013-1917
/ XSA-44. (CVE-2013-1917)

- Current Xend allowing multiple call destroy for the same
domain, this lead multiple hard resets(FLR) for pci
pass-through, and some controller might failed. In our
test, we pass through 2 LSI HAB controllers to the PVHVM
guest, after guest brought up, call xm-destroy twice,
the adapters's BIOS will hung, and we had to reboot the
server to recovery it. BTW: I had send this patch to Xen
maillist, but developer said Xend will obsolete and
would not review and merge the fix.

See also :

Solution :

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

Risk factor :

Medium / CVSS Base Score : 4.7
CVSS Temporal Score : 4.1
Public Exploit Available : false

Family: OracleVM Local Security Checks

Nessus Plugin ID: 79503 ()

Bugtraq ID: 58880

CVE ID: CVE-2013-1917

Ready to Amp Up Your Nessus Experience?

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

Buy Nessus Professional Now