[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