Bug 1278496 (CVE-2015-8104, xsa156)

Created attachment 1090189 [details]
Proposed patch

Patch proposed for Xen 4.3.x

Created attachment 1090190 [details]
Proposed patch

Patch proposed for Xen 4.4.x

Created attachment 1090191 [details]
Proposed patch

Patch proposed for Xen 4.5.x

Created attachment 1090193 [details]
Proposed patch

Patch proposed for Xen 4.6.x

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/.

Created kernel tracking bugs for this issue:

Affects: fedora-all [bug 1279691]

Created xen tracking bugs for this issue:

Affects: fedora-all [bug 1279690]

(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?

(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.

(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.

(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.

(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.

(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 .

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.

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.

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.

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.

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.

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.

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

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

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

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

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

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

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