Request for stable 3.18.y and 3.14.y inclusion: Fix for CVE-2015-3290 (nmi)

* Request for stable 3.18.y and 3.14.y inclusion: Fix for CVE-2015-3290 (nmi)
@ 2015-08-17 10:39 Thomas D.
  2015-08-17 13:23 ` Greg KH
  0 siblings, 1 reply; 21+ messages in thread
From: Thomas D. @ 2015-08-17 10:39 UTC (permalink / raw)
  To: stable

Hi,

I don't see the fixes for CVE-2015-3290 in 3.18.y or 3.14.y and can't
find them quequed so I am requesting the following commits for inclusion in

 - 3.18
 - 3.14

I am quoting from 4.1.6:

commit 37df1cab0c4d4ec0f4bec868b2e26b84e725c478
Author: Andy Lutomirski <luto@kernel.org>
Date:   Wed Jul 15 10:29:38 2015 -0700

    x86/nmi/64: Use DF to avoid userspace RSP confusing nested NMI detection

    commit 810bc075f78ff2c221536eb3008eac6a492dba2d upstream.

    We have a tricky bug in the nested NMI code: if we see RSP
    pointing to the NMI stack on NMI entry from kernel mode, we
    assume that we are executing a nested NMI.

    This isn't quite true.  A malicious userspace program can point
    RSP at the NMI stack, issue SYSCALL, and arrange for an NMI to
    happen while RSP is still pointing at the NMI stack.

    Fix it with a sneaky trick.  Set DF in the region of code that
    the RSP check is intended to detect.  IRET will clear DF
    atomically.

    ( Note: other than paravirt, there's little need for all this
      complexity. We could check RIP instead of RSP. )

commit d8246ca4e3ce08c9ed98ebe292f36ee2bc5f54ab
Author: Andy Lutomirski <luto@kernel.org>
Date:   Wed Jul 15 10:29:37 2015 -0700

    x86/nmi/64: Reorder nested NMI checks

    commit a27507ca2d796cfa8d907de31ad730359c8a6d06 upstream.

    Check the repeat_nmi .. end_repeat_nmi special case first.  The
    next patch will rework the RSP check and, as a side effect, the
    RSP check will no longer detect repeat_nmi .. end_repeat_nmi, so
    we'll need this ordering of the checks.

    Note: this is more subtle than it appears.  The check for
    repeat_nmi .. end_repeat_nmi jumps straight out of the NMI code
    instead of adjusting the "iret" frame to force a repeat.  This
    is necessary, because the code between repeat_nmi and
    end_repeat_nmi sets "NMI executing" and then writes to the
    "iret" frame itself.  If a nested NMI comes in and modifies the
    "iret" frame while repeat_nmi is also modifying it, we'll end up
    with garbage.  The old code got this right, as does the new
    code, but the new code is a bit more explicit.

    If we were to move the check right after the "NMI executing"
    check, then we'd get it wrong and have random crashes.

    ( Because the "NMI executing" check would jump to the code that would
      modify the "iret" frame without checking if the interrupted NMI was
      currently modifying it. )

commit 1dd191d72fdfb46988d8c97c8b19fc6d83d44d3e
Author: Andy Lutomirski <luto@kernel.org>
Date:   Wed Jul 15 10:29:36 2015 -0700

    x86/nmi/64: Improve nested NMI comments

    commit 0b22930ebad563ae97ff3f8d7b9f12060b4c6e6b upstream.

    I found the nested NMI documentation to be difficult to follow.
    Improve the comments.

commit 60e6cbaf875edd9aef40948d0790decb8e1a77cc
Author: Andy Lutomirski <luto@kernel.org>
Date:   Wed Jul 15 10:29:35 2015 -0700

    x86/nmi/64: Switch stacks on userspace NMI entry

    commit 9b6e6a8334d56354853f9c255d1395c2ba570e0a upstream.

    Returning to userspace is tricky: IRET can fail, and ESPFIX can
    rearrange the stack prior to IRET.

    The NMI nesting fixup relies on a precise stack layout and
    atomic IRET.  Rather than trying to teach the NMI nesting fixup
    to handle ESPFIX and failed IRET, punt: run NMIs that came from
    user mode on the normal kernel stack.

    This will make some nested NMIs visible to C code, but the C
    code is okay with that.

    As a side effect, this should speed up perf: it eliminates an
    RDMSR when NMIs come from user mode.

commit f163d838c24833d4493e693a612be275b723d5e8
Author: Andy Lutomirski <luto@kernel.org>
Date:   Wed Jul 15 10:29:34 2015 -0700

    x86/nmi/64: Remove asm code that saves CR2

    commit 0e181bb58143cb4a2e8f01c281b0816cd0e4798e upstream.

    Now that do_nmi saves CR2, we don't need to save it in asm.

commit e0146756cb2b7122adbe9b5bb97da4a99c5437b3
Author: Andy Lutomirski <luto@kernel.org>
Date:   Wed Jul 15 10:29:33 2015 -0700

    x86/nmi: Enable nested do_nmi() handling for 64-bit kernels

    commit 9d05041679904b12c12421cbcf9cb5f4860a8d7b upstream.

    32-bit kernels handle nested NMIs in C.  Enable the exact same
    handling on 64-bit kernels as well.  This isn't currently
    necessary, but it will become necessary once the asm code starts
    allowing limited nesting.

-Thomas

^ permalink raw reply	[flat|nested] 21+ messages in thread