[Oraclevm-errata] OVMSA-2013-0031 Important: Oracle VM 3.2 xen security update

Errata Announcements for Oracle VM oraclevm-errata at oss.oracle.com
Fri Apr 19 12:29:48 PDT 2013


Oracle VM Security Advisory OVMSA-2013-0031

The following updated rpms for Oracle VM 3.2 have been uploaded to the 
Unbreakable Linux Network:

x86_64:
xen-4.1.3-25.el5.6.x86_64.rpm
xen-devel-4.1.3-25.el5.6.x86_64.rpm
xen-tools-4.1.3-25.el5.6.x86_64.rpm


SRPMS:
http://oss.oracle.com/oraclevm/server/3.2/SRPMS-updates/xen-4.1.3-25.el5.6.src.rpm

Description of changes:

[4.1.3-25.el5.6]
- 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.
   Reported-by: Wei Liu <wei.liu2 at citrix.com>
   Signed-off-by: Jan Beulich <jbeulich at suse.com>
   Reviewed-by: Tim Deegan <tim at xen.org>
   John Haxby <john.haxby at oracle.com>
  Signed-off-by: Chuck Anderson <chuck.anderson at oracle.com> [bug 16627108]

[4.1.3-25.el5.5]
- 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 MAP_PIRQ_TYPE_MSI
   - 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.
   Signed-off-by: Jan Beulich <jbeulich at suse.com>
   Acked-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>
   Signed-off-by: Chuck Anderson <chuck.anderson at oracle.com> [bug 16627078]

[4.1.3-25.el5.4]
- 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
   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.
   Reported-by: Andrew Cooper <andrew.cooper3 at citirx.com>
   Signed-off-by: Jan Beulich <jbeulich at suse.com>
   Tested-by: Andrew Cooper <andrew.cooper3 at citrix.com>
   Acked-by: Andrew Cooper <andrew.cooper3 at citrix.com>
   Signed-off-by: Chuck Anderson <chuck.anderson at oracle.com>
   Reviewed-by: John Haxby <john.haxby at oracle.com> [bug 16627030] 
{CVE-2013-1917}




More information about the Oraclevm-errata mailing list