Bug 1278496 (CVE-2015-8104, xsa156) - CVE-2015-8104 virt: guest to host DoS by triggering an infinite loop in microcode via #DB exception
Summary: CVE-2015-8104 virt: guest to host DoS by triggering an infinite loop in micro...
Status: CLOSED ERRATA
Alias: CVE-2015-8104, xsa156
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
high
high
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard: impact=important,public=20151110,repo...
Keywords: Security
Depends On: 1279467 1279468 1279469 1279470 1279474 1279476 1279477 1279478 1279479 1279690 1279691
Blocks: 1277175
TreeView+ depends on / blocked
 
Reported: 2015-11-05 15:49 UTC by Adam Mariš
Modified: 2019-06-08 20:50 UTC (History)
21 users (show)

(edit)
It was found that the x86 ISA (Instruction Set Architecture) is prone to a denial of service attack inside a virtualized environment in the form of an infinite loop in the microcode due to the way (sequential) delivering of benign exceptions such as #DB (debug exception) is handled. A privileged user inside a guest could use this flaw to create denial of service conditions on the host kernel.
Clone Of:
(edit)
Last Closed: 2016-01-07 14:29:12 UTC


Attachments (Terms of Use)
Proposed patch (4.73 KB, patch)
2015-11-05 15:52 UTC, Adam Mariš
no flags Details | Diff
Proposed patch (4.71 KB, patch)
2015-11-05 15:53 UTC, Adam Mariš
no flags Details | Diff
Proposed patch (4.76 KB, patch)
2015-11-05 15:53 UTC, Adam Mariš
no flags Details | Diff
Proposed patch (4.77 KB, patch)
2015-11-05 15:54 UTC, Adam Mariš
no flags Details | Diff


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2015:2552 normal SHIPPED_LIVE Important: kernel security and bug fix update 2015-12-08 15:51:34 UTC
Red Hat Product Errata RHSA-2015:2636 normal SHIPPED_LIVE Important: kernel security and bug fix update 2015-12-15 18:57:46 UTC
Red Hat Product Errata RHSA-2015:2645 normal SHIPPED_LIVE Important: kernel security and bug fix update 2015-12-15 19:36:40 UTC
Red Hat Product Errata RHSA-2016:0004 normal SHIPPED_LIVE Important: kernel security update 2016-01-07 18:52:46 UTC
Red Hat Product Errata RHSA-2016:0024 normal SHIPPED_LIVE Important: kernel security and bug fix update 2016-01-12 19:48:34 UTC
Red Hat Product Errata RHSA-2016:0046 normal SHIPPED_LIVE Important: kernel security update 2016-01-19 17:51:29 UTC
Red Hat Product Errata RHSA-2016:0103 normal SHIPPED_LIVE Important: kernel security, bug fix, and enhancement update 2016-02-02 21:58:30 UTC

Description Adam Mariš 2015-11-05 15:49:08 UTC
It was found that a malicious HVM guest administrator can cause DoS, specifically prevent use of physical CPU for significant, perhaps indefinite period. When a benign exception occurs while delivering another benign exception, it is architecturally specified that these would be delivered sequentially. There are, however, cases where this results in an infinite loop inside the CPU, which (in the virtualized case) can be broken only by intercepting delivery of the respective exception.

When a guest sets up a hardware breakpoint covering a data structure involved in delivering #DB (Debug Exception), upon completion of the delivery of the first exception another #DB will need to be delivered. The effects slightly differ depending on further guest characteristics:

* Guests running in 32-bit mode would be expected to sooner or later encounter another fault due to the stack pointer decreasing during each iteration of the loop. The most likely case would be #PF (Page Fault) due to running into unmapped virtual space. However, an infinite loop cannot be excluded (e.g. when the guest is running with paging disabled).

* Guests running in long mode, but not using the IST (Interrupt Stack Table) feature for the IDT entry corresponding to #DB would behave similarly to guests running in 32-bit mode, just that the larger virtual address space allows for a much longer loop. The loop can't, however, be infinite, as eventually the stack pointer would move into non-canonical address space, causing #SS (Stack Fault) instead.

* Guests running in long mode and using the IST for the IDT entry corresponding to #DB would enter an infinite loop, as the stack pointer wouldn't change between #DB instances.

If a host watchdog (Xen or dom0) is in use, this can lead to a watchdog timeout and consequently a reboot of the host. If another, innocent, guest, is configured with a watchdog, this issue can lead to a reboot of such a guest.

A privileged user inside guest could use this flaw to crash the host kernel resulting in DoS.

For KVM virtualisation, it only affects the AMD processor support, as for Intel it already intercepts the #DB exception.

Upstream KVM patch:
-------------------
  -> http://permalink.gmane.org/gmane.linux.kernel/2082332

References:
-----------
  -> http://www.openwall.com/lists/oss-security/2015/11/10/1

Comment 1 Adam Mariš 2015-11-05 15:52 UTC
Created attachment 1090189 [details]
Proposed patch

Patch proposed for Xen 4.3.x

Comment 2 Adam Mariš 2015-11-05 15:53 UTC
Created attachment 1090190 [details]
Proposed patch

Patch proposed for Xen 4.4.x

Comment 3 Adam Mariš 2015-11-05 15:53 UTC
Created attachment 1090191 [details]
Proposed patch

Patch proposed for Xen 4.5.x

Comment 4 Adam Mariš 2015-11-05 15:54 UTC
Created attachment 1090193 [details]
Proposed patch

Patch proposed for Xen 4.6.x

Comment 5 Prasad J Pandit 2015-11-09 14:00:57 UTC
Statement:

This issue affects the version of the kvm & xen packages as shipped with Red Hat Enterprise Linux 5.

This issue does not affect the versions of the kernel package as shipped with
Red Hat Enterprise Linux 5 and Red Hat Enterprise MRG 2.

This issue affects the version of Linux kernel as shipped with
Red Hat Enterprise Linux 6 and 7. Future kernel updates for the respective releases may address this issue.

Red Hat Enterprise Linux 5 is now in Production Phase 3 of the support and
maintenance life cycle. Thus it is not currently planned to be addressed in future updates. For additional information, refer to the Red Hat Enterprise Linux Life Cycle: https://access.redhat.com/support/policy/updates/errata/.

Comment 8 Prasad J Pandit 2015-11-10 03:29:31 UTC
Created kernel tracking bugs for this issue:

Affects: fedora-all [bug 1279691]

Comment 9 Prasad J Pandit 2015-11-10 03:29:41 UTC
Created xen tracking bugs for this issue:

Affects: fedora-all [bug 1279690]

Comment 10 Mohammed Gamal 2015-11-10 13:49:53 UTC
(In reply to Adam Mariš from comment #0)
> It was found that a malicious HVM guest administrator can cause DoS,
> specifically prevent use of physical CPU for significant, perhaps indefinite
> period. When a benign exception occurs while delivering another benign
> exception, it is architecturally specified that these would be delivered
> sequentially. There are, however, cases where this results in an infinite
> loop inside the CPU, which (in the virtualized case) can be broken only by
> intercepting delivery of the respective exception.
> 
> When a guest sets up a hardware breakpoint covering a data structure
> involved in delivering #DB (Debug Exception), upon completion of the
> delivery of the first exception another #DB will need to be delivered. The
> effects slightly differ depending on further guest characteristics:
> 
> * Guests running in 32-bit mode would be expected to sooner or later
> encounter another fault due to the stack pointer decreasing during each
> iteration of the loop. The most likely case would be #PF (Page Fault) due to
> running into unmapped virtual space. However, an infinite loop cannot be
> excluded (e.g. when the guest is running with paging disabled).
> 
> * Guests running in long mode, but not using the IST (Interrupt Stack Table)
> feature for the IDT entry corresponding to #DB would behave similarly to
> guests running in 32-bit mode, just that the larger virtual address space
> allows for a much longer loop. The loop can't, however, be infinite, as
> eventually the stack pointer would move into non-canonical address space,
> causing #SS (Stack Fault) instead.
> 
> * Guests running in long mode and using the IST for the IDT entry
> corresponding to #DB would enter an infinite loop, as the stack pointer
> wouldn't change between #DB instances.
> 
> If a host watchdog (Xen or dom0) is in use, this can lead to a watchdog
> timeout and consequently a reboot of the host. If another, innocent, guest,
> is configured with a watchdog, this issue can lead to a reboot of such a
> guest.
> 
> A privileged user inside guest could use this flaw to crash the host kernel
> resulting in DoS.
> 
> For KVM virtualisation, it only affects the AMD processor support, as for
> Intel it already intercepts the #DB exception.

AMD does intercept #DB exceptions as far as I can see

static int (*const svm_exit_handlers[])(struct vcpu_svm *svm) = {
...
       [SVM_EXIT_EXCP_BASE + DB_VECTOR]        = db_interception,
...
}

I can see that the case where the guest has no debugger attached is already handled as well

static int db_interception(struct vcpu_svm *svm)
{
        struct kvm_run *kvm_run = svm->vcpu.run;

        if (!(svm->vcpu.guest_debug &
              (KVM_GUESTDBG_SINGLESTEP | KVM_GUESTDBG_USE_HW_BP)) &&
                !svm->nmi_singlestep) {
                kvm_queue_exception(&svm->vcpu, DB_VECTOR);
                return 1;
        }
...
}

Am I correct?

Comment 11 Petr Matousek 2015-11-10 13:52:43 UTC
(In reply to Mohammed Gamal from comment #10)
<snip>
> I can see that the case where the guest has no debugger attached is already
> handled as well
<snip>
> Am I correct?

As per comment #0 and regardless whether debugger is attached or not, KVM hosts using AMD SVM are not affected by this issue.

Comment 12 Mohammed Gamal 2015-11-10 13:55:33 UTC
(In reply to Petr Matousek from comment #11)
> (In reply to Mohammed Gamal from comment #10)
> <snip>
> > I can see that the case where the guest has no debugger attached is already
> > handled as well
> <snip>
> > Am I correct?
> 
> As per comment #0 and regardless whether debugger is attached or not, KVM
> hosts using AMD SVM are not affected by this issue.


It says comment #0:
> For KVM virtualisation, it only affects the AMD processor support, as for
> Intel it already intercepts the #DB exception.

I thought that meant AMD SVM is affected while Intel VMX isn't.

Comment 13 Petr Matousek 2015-11-10 14:17:21 UTC
(In reply to Mohammed Gamal from comment #12)
> (In reply to Petr Matousek from comment #11)
> > (In reply to Mohammed Gamal from comment #10)
> > <snip>
> > > I can see that the case where the guest has no debugger attached is already
> > > handled as well
> > <snip>
> > > Am I correct?
> > 
> > As per comment #0 and regardless whether debugger is attached or not, KVM
> > hosts using AMD SVM are not affected by this issue.
> 
> 
> It says comment #0:
> > For KVM virtualisation, it only affects the AMD processor support, as for
> > Intel it already intercepts the #DB exception.
> 
> I thought that meant AMD SVM is affected while Intel VMX isn't.

Yes, that's correct, I've got it reversed in my last comment, sorry. For posterity, hosts using Intel VMX ARE NOT affected while hosts using AMD SVM ARE affected by this issue.

Comment 14 Mohammed Gamal 2015-11-10 14:24:09 UTC
(In reply to Petr Matousek from comment #13)
> (In reply to Mohammed Gamal from comment #12)
> > (In reply to Petr Matousek from comment #11)
> > > (In reply to Mohammed Gamal from comment #10)

<snip>
> > 
> > I thought that meant AMD SVM is affected while Intel VMX isn't.
> 
> Yes, that's correct, I've got it reversed in my last comment, sorry. For
> posterity, hosts using Intel VMX ARE NOT affected while hosts using AMD SVM
> ARE affected by this issue.

I see that all the propose patches here are for Xen not KVM.

Is there a fix required in the first place? Since as far as I could see #DB exceptions are already handled by AMD SVM code (see comment #10). 
I don't see where the corner case that might be causing this issue is, but I am not sure if I am correct.

Comment 15 Petr Matousek 2015-11-10 14:30:02 UTC
(In reply to Mohammed Gamal from comment #14)
> Is there a fix required in the first place? Since as far as I could see #DB
> exceptions are already handled by AMD SVM code (see comment #10). 
> I don't see where the corner case that might be causing this issue is, but I
> am not sure if I am correct.

The upstream KVM patch for this issue can be found at http://permalink.gmane.org/gmane.linux.kernel/2082332 .

Comment 17 Fedora Update System 2015-11-19 09:54:51 UTC
kernel-4.2.6-300.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.

Comment 18 Fedora Update System 2015-11-19 12:19:58 UTC
kernel-4.2.6-200.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.

Comment 19 Fedora Update System 2015-11-20 23:22:03 UTC
kernel-4.1.13-100.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.

Comment 20 Fedora Update System 2015-11-20 23:23:09 UTC
xen-4.4.3-8.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.

Comment 21 Fedora Update System 2015-11-21 16:51:43 UTC
xen-4.5.2-2.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.

Comment 22 Fedora Update System 2015-11-23 00:24:29 UTC
xen-4.5.2-2.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.

Comment 23 errata-xmlrpc 2015-12-08 10:52:58 UTC
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 7

Via RHSA-2015:2552 https://rhn.redhat.com/errata/RHSA-2015-2552.html

Comment 24 errata-xmlrpc 2015-12-15 14:01:40 UTC
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 6

Via RHSA-2015:2636 https://rhn.redhat.com/errata/RHSA-2015-2636.html

Comment 25 errata-xmlrpc 2015-12-15 14:38:04 UTC
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 6.5 AUS - Server Only

Via RHSA-2015:2645 https://rhn.redhat.com/errata/RHSA-2015-2645.html

Comment 26 errata-xmlrpc 2016-01-07 13:54:10 UTC
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 6.4 AUS - Server Only

Via RHSA-2016:0004 https://rhn.redhat.com/errata/RHSA-2016-0004.html

Comment 27 errata-xmlrpc 2016-01-12 14:51:35 UTC
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 6.6 EUS - Server and Compute Node Only

Via RHSA-2016:0024 https://rhn.redhat.com/errata/RHSA-2016-0024.html

Comment 28 errata-xmlrpc 2016-01-19 12:52:49 UTC
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 6.2 AUS

Via RHSA-2016:0046 https://rhn.redhat.com/errata/RHSA-2016-0046.html

Comment 29 errata-xmlrpc 2016-02-02 16:59:17 UTC
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 7.1 EUS - Server and Compute Node Only

Via RHSA-2016:0103 https://rhn.redhat.com/errata/RHSA-2016-0103.html


Note You need to log in before you can comment on or make changes to this bug.