A vulnerability was reported in NetBSD. A local user can obtain elevated privileges on the target system.
Version(s): 4.0.*, 5.0.*, 5.1, 6.0 Beta
On Intel CPUs, the sysret instruction can be manipulated into returning to specific non-canonical addresses, which may yield a CPU reset. We cannot currently rule out with utter confidence that this vulnerability could not also be used to execute code with kernel privilege instead of crashing the system.
This is a vulnerability following from a difference of behavior of sysret in Intel's version of the amd64 architecture, em64t.
System calls may be implemented as using the em64t syscall/sysret instruction pair.
syscall saves the context of the calling unprivileged process before executing a system call in kernel mode; sysret restores it and resumes ordinary operations in user mode.
In the Intel implementation of sysret, if you have invalid information about the "next instruction" address in your saved context, the sysret instruction will trigger a trap in kernel space. However the sysret instruction is executed with the user stack pointer already loaded, so the kernel fault frame is written to the user stack.
The kernel is unable to safely recover from this, so must ensure that the trap doesn't happen.
If your invalid "next instruction" address is in kernel space or in user space (and in the latter case, not where your program is) the program will segfault.
If it is in the gap between user space and kernel space, the CPU will reset, except if someone managed to seed the address location with a valid instruction.
Denial of service via local system, Root access via local system, User access via local system.
The vendor has issued a fix that will disallow sysret to an invalid address.