Xen Security Advisory 196 (CVE-2016-9377, CVE-2016-9378) - x86 software interrupt injection mis-handled

Xen Security Advisory 196 (CVE-2016-9377, CVE-2016-9378) - x86 software interrupt injection mis-handled

[Xen.org security team]

[-- Attachment #1: Type: text/plain, Size: 3894 bytes --]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

     Xen Security Advisory CVE-2016-9377,CVE-2016-9378 / XSA-196
                              version 3

             x86 software interrupt injection mis-handled

UPDATES IN VERSION 3
====================

Public release.

ISSUE DESCRIPTION
=================

There are two closely-related bugs.

When Xen emulates instructions which generate software interrupts it
needs to perform a privilege check involving an IDT lookup.  This
check is sometimes erroneously conducted as if the IDT had the format
for a 32-bit guest, when in fact it is in the 64-bit format.  Xen will
then read the wrong part of the IDT and interpret it in an unintended
manner.  (CVE-2016-9377)

When Xen emulates instructions which generate software interrupts, and
chooses to deliver the software interrupt, it may try to use the
method intended for injecting exceptions.  This is incorrect, and
results in a guest crash.  (CVE-2016-9378)

These instructions are not ususally handled by the emulator.
Exploiting the bug requires ability to force use of the emulator.

IMPACT
======

An unprivileged guest user program may be able to crash the guest.

VULNERABLE SYSTEMS
==================

Xen versions 4.5 and newer are vulnerable.  Older versions are not
vulnerable.

The vulnerability is only exposed on AMD hardware lacking the NRip
feature.  AMD hardware with the NRip feature, and all Intel hardware,
is not vulnerable.

Xen prints information about CPU features on boot.  If you see this:
    (XEN) SVM: Supported advanced features:
    ...
    (XEN)  - Next-RIP Saved on #VMEXIT
then you are not vulnerable because you have an AMD CPU with NRip.
If you see this:
    (XEN) VMX: Supported advanced features:
then you are not vulnerable because you have an Intel CPU.

The vulnerability is only exposed on HVM guests.

ARM systems are NOT vulnerable.

MITIGATION
==========

Running only PV guests will avoid this issue.

CREDITS
=======

This issue was discovered by Andrew Cooper of Citrix.

RESOLUTION
==========

Applying the attached patches resolves this issue.

xsa196-000*.patch      xen-unstable, Xen 4.7.x, Xen 4.6.x, Xen 4.5.x

$ sha256sum xsa196*
c4122280f3786416231ae5f0660123446d29e9ac5cd3ffb92784ed36edeec8b7  xsa196-0001-x86-emul-Correct-the-IDT-entry-calculation-in-inject.patch
25671c44c746d4d0e8f7e2b109926c013b440e0bf225156282052ec38536e347  xsa196-0002-x86-svm-Fix-injection-of-software-interrupts.patch
$

DEPLOYMENT DURING EMBARGO
=========================

Deployment of the patches and/or mitigations described above (or
others which are substantially similar) is permitted during the
embargo, even on public-facing systems with untrusted guest users and
administrators.

But: Distribution of updated software is prohibited (except to other
members of the predisclosure list).

Predisclosure list members who wish to deploy significantly different
patches and/or mitigations, please contact the Xen Project Security
Team.

(Note: this during-embargo deployment notice is retained in
post-embargo publicly released Xen Project advisories, even though it
is then no longer applicable.  This is to enable the community to have
oversight of the Xen Project Security Team's decisionmaking.)

For more information about permissible uses of embargoed information,
consult the Xen Project community's agreed Security Policy:
  http://www.xenproject.org/security-policy.html
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJYNDMVAAoJEIP+FMlX6CvZZ7MH/36KnwbAxmRHtUDIpQF/Syoh
Lc8s6gNV1oOzcCpFgz+gSyIOMzp7KWieKQiVX1HbI0lnLYK/sRa77VNV/Y9bUt+Y
y9b9QOZRDHoO92dZ4Ym/hzdtaNkdOQX/JAfy+E5pCGuqPtH/Jy5NuwVL8W7V8PNM
QTHmvbgB4/Y2U6QqWpIP+S7oC0A9iuIf9eekd6ZTpqTadPFylTe2WX22mns1TEtN
3Z0NX737AjQLyUVnUoJ32sITCBk6tGutvvEmOc2Y+4eMrUvKSoafVy+5IZcTGwLp
3ke5sDNN1tOpzmqbXgWXBsVkpjWf2i0NW0dl5jh8/tN5FtrTuByd193dJGSKzEE=
=IE45
-----END PGP SIGNATURE-----

[-- Attachment #2: xsa196-0001-x86-emul-Correct-the-IDT-entry-calculation-in-inject.patch --]
[-- Type: application/octet-stream, Size: 2812 bytes --]

From: Andrew Cooper <andrew.cooper3@citrix.com>
Subject: x86/emul: Correct the IDT entry calculation in inject_swint()

The logic, as introduced in c/s 36ebf14ebe "x86/emulate: support for emulating
software event injection" is buggy.  The size of an IDT entry depends on long
mode being active, not the width of the code segment currently in use.

In particular, this means that a compatibility code segment which hits
emulation for software event injection will end up using an incorrect offset
in the IDT for DPL/Presence checking.  In practice, this only occurs on old
AMD hardware lacking NRip support; all newer AMD hardware, and all Intel
hardware bypass this path in the emulator.

While here, fix a minor issue with reading the IDT entry.  The return value
from ops->read() wasn't checked, but in reality the only failure case is if a
pagefault occurs.  This is not a realistic problem as the kernel will almost
certainly crash with a double fault if this setup actually occured.

This is part of XSA-196.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
---
 xen/arch/x86/x86_emulate/x86_emulate.c | 15 +++++++++++----
 1 file changed, 11 insertions(+), 4 deletions(-)

diff --git a/xen/arch/x86/x86_emulate/x86_emulate.c b/xen/arch/x86/x86_emulate/x86_emulate.c
index 7a707dc..f74aa8f 100644
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -1630,10 +1630,16 @@ static int inject_swint(enum x86_swint_type type,
     {
         if ( !in_realmode(ctxt, ops) )
         {
-            unsigned int idte_size = (ctxt->addr_size == 64) ? 16 : 8;
-            unsigned int idte_offset = vector * idte_size;
+            unsigned int idte_size, idte_offset;
             struct segment_register idtr;
             uint32_t idte_ctl;
+            int lm = in_longmode(ctxt, ops);
+
+            if ( lm < 0 )
+                return X86EMUL_UNHANDLEABLE;
+
+            idte_size = lm ? 16 : 8;
+            idte_offset = vector * idte_size;
 
             /* icebp sets the External Event bit despite being an instruction. */
             error_code = (vector << 3) | ECODE_IDT |
@@ -1661,8 +1667,9 @@ static int inject_swint(enum x86_swint_type type,
              * Should strictly speaking read all 8/16 bytes of an entry,
              * but we currently only care about the dpl and present bits.
              */
-            ops->read(x86_seg_none, idtr.base + idte_offset + 4,
-                      &idte_ctl, sizeof(idte_ctl), ctxt);
+            if ( (rc = ops->read(x86_seg_none, idtr.base + idte_offset + 4,
+                                 &idte_ctl, sizeof(idte_ctl), ctxt)) )
+                goto done;
 
             /* Is this entry present? */
             if ( !(idte_ctl & (1u << 15)) )

[-- Attachment #3: xsa196-0002-x86-svm-Fix-injection-of-software-interrupts.patch --]
[-- Type: application/octet-stream, Size: 3476 bytes --]

From: Andrew Cooper <andrew.cooper3@citrix.com>
Subject: x86/svm: Fix injection of software interrupts

The non-NextRip logic in c/s 36ebf14eb "x86/emulate: support for emulating
software event injection" was based on an older version of the AMD software
manual.  The manual was later corrected, following findings from that series.

I took the original wording of "not supported without NextRIP" to mean that
X86_EVENTTYPE_SW_INTERRUPT was not eligible for use.  It turns out that this
is not the case, and the new wording is clearer on the matter.

Despite testing the original patch series on non-NRip hardware, the
swint-emulation XTF test case focuses on the debug vectors; it never ended up
executing an `int $n` instruction for a vector which wasn't also an exception.

During a vmentry, the use of X86_EVENTTYPE_HW_EXCEPTION comes with a vector
check to ensure that it is only used with exception vectors.  Xen's use of
X86_EVENTTYPE_HW_EXCEPTION for `int $n` injection has always been buggy on AMD
hardware.

Fix this by always using X86_EVENTTYPE_SW_INTERRUPT.

Print and decode the eventinj information in svm_vmcb_dump(), as it has
several invalid combinations which cause vmentry failures.

This is part of XSA-196.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
---
 xen/arch/x86/hvm/svm/svm.c      | 13 +++++--------
 xen/arch/x86/hvm/svm/svmdebug.c |  4 ++++
 2 files changed, 9 insertions(+), 8 deletions(-)

diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index 4391744..76efc3e 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -1231,17 +1231,14 @@ static void svm_inject_trap(const struct hvm_trap *trap)
     {
     case X86_EVENTTYPE_SW_INTERRUPT: /* int $n */
         /*
-         * Injection type 4 (software interrupt) is only supported with
-         * NextRIP support.  Without NextRIP, the emulator will have performed
-         * DPL and presence checks for us.
+         * Software interrupts (type 4) cannot be properly injected if the
+         * processor doesn't support NextRIP.  Without NextRIP, the emulator
+         * will have performed DPL and presence checks for us, and will have
+         * moved eip forward if appropriate.
          */
         if ( cpu_has_svm_nrips )
-        {
             vmcb->nextrip = regs->eip + _trap.insn_len;
-            event.fields.type = X86_EVENTTYPE_SW_INTERRUPT;
-        }
-        else
-            event.fields.type = X86_EVENTTYPE_HW_EXCEPTION;
+        event.fields.type = X86_EVENTTYPE_SW_INTERRUPT;
         break;
 
     case X86_EVENTTYPE_PRI_SW_EXCEPTION: /* icebp */
diff --git a/xen/arch/x86/hvm/svm/svmdebug.c b/xen/arch/x86/hvm/svm/svmdebug.c
index ded5d19..f93dfed 100644
--- a/xen/arch/x86/hvm/svm/svmdebug.c
+++ b/xen/arch/x86/hvm/svm/svmdebug.c
@@ -48,6 +48,10 @@ void svm_vmcb_dump(const char *from, struct vmcb_struct *vmcb)
            vmcb->tlb_control,
            (unsigned long long)vmcb->_vintr.bytes,
            (unsigned long long)vmcb->interrupt_shadow);
+    printk("eventinj %016"PRIx64", valid? %d, ec? %d, type %u, vector %#x\n",
+           vmcb->eventinj.bytes, vmcb->eventinj.fields.v,
+           vmcb->eventinj.fields.ev, vmcb->eventinj.fields.type,
+           vmcb->eventinj.fields.vector);
     printk("exitcode = %#Lx exitintinfo = %#Lx\n",
            (unsigned long long)vmcb->exitcode,
            (unsigned long long)vmcb->exitintinfo.bytes);

[-- Attachment #4: Type: text/plain, Size: 127 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel