The Intel SYSRET privilege escalation (2012)
blog.xenproject.org
blog.xenproject.org
So, inevitably, there's a Windows exploit.
AMD doesn't seem to be vulnerable, so you'd imagine that code couldn't rely on this behavior because then it would fail on AMD chips, but... well, once you've read enough of The Old New Thing, you get a feel for how gonzo some developers get with This Never Fails and This Will Never Change, and if they have to write different codepaths for Intel and AMD instead of doing things sanely, that doesn't seem such a huge imposition to the irrational mind.
In linux-mainline/arch/x86/entry/entry_64.S, at syscall_return you'll find a comment explaining that a more complicated and slower method will used to return to usespace should a few conditions not be met. https://github.com/torvalds/linux/blob/master/arch/x86/entry...
The original fix is from 2006, then at x86_64/kernel/entry.S https://github.com/torvalds/linux/commit/7bf36bbc5e0c09271f9...
[PATCH] x86_64: When user could have changed RIP always force IRET
Intel EM64T CPUs handle uncanonical return addresses differently
from AMD CPUs.
The exception is reported in the SYSRET, not the next instruction.
This leads to the kernel exception handler running on the user stack
with the wrong GS because the kernel didn't expect exceptions
on this instruction.
This version of the patch has the teething problems that plagued an earlier
version fixed.
This is CVE-2006-0744
Thanks to Ernie Petrides and Asit B. Mallick for analysis and initial
patches.