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@xxxxxxxxxx>
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@xxxxxxxxxx>
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@xxxxxxxxxx>
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@xxxxxxxxxx>
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@xxxxxxxxxx>
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@xxxxxxxxxx>
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
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html