CVE-2018-3665: Lazy State Save/Restore As The Latest CPU Speculative Execution Issue

Written by Michael Larabel in Linux Kernel on 13 June 2018 at 05:18 PM EDT. 36 Comments
The latest speculative execution vulnerability affecting modern CPUs has now been made public: Lazy State Save/Restore, a.k.a. CVE-2018-3665.

This vulnerability concerns saving/restore state when switching between applications. The newly-disclosed vulnerability exploits lazy-state restores for floating-point state when context switching, which is done as a performance optimization, to obtain information about the activity of other applications on the system.
x86 has a hardware mechanism for lazy FPU context switching. On a task switch, %cr0.ts (Task Switched) gets set, and the next instruction to touch floating point state raises an #NM (No Math, later known as Device Not Available) exception.

Traditionally, FPU state has been large in comparison to available bandwidth (and therefore slow to switch) and not used as frequently as cpu tasks tend to switch. This mechanism allows the OS to only switch FPU when necessary, which in turn increases performance.

Some CPUs however speculate past an #NM exception, allowing register content to be leaked by a side-channel.

This vulnerability is what BSDs like OpenBSD and DragonFlyBSD began patching against last week.

Mitigating this lazy state save/restore vulnerability does not require CPU microcode updates, but does require updated kernel patches. Those on RHEL7 for instance though already default to safe floating point restores on Intel 64-bit CPUs of the past several years that support the XSAVEOPT extension. Hypervisor patches are also needed for VM users.

This vulnerability currently appears to only affect Intel Core (Nehalem and newer) CPUs.

As of writing this article, CVE-2018-3665 hasn't yet been made public and we have just been supplied with limited details so far, so check back for updates as more information gets cleared.

Update: Additional information is now available here via the researchers that uncovered the issue. It looks like recent Linux kernel users where eagerfpu defaults to enabled by default are covered. Additionally, the performance impact of that default kernel change was expected to cause no major performance hit, though I'll run some eagerfpu comparison benchmark runs with the latest kernel to see how it performs (that change happened back in 2016).
Related News
About The Author
Author picture

Michael Larabel is the principal author of and founded the site in 2004 with a focus on enriching the Linux hardware experience. Michael has written more than 20,000 articles covering the state of Linux hardware support, Linux performance, graphics drivers, and other topics. Michael is also the lead developer of the Phoronix Test Suite, Phoromatic, and automated benchmarking software. He can be followed via Twitter, LinkedIn, or contacted via

Popular News This Week