In the Linux kernel, the following vulnerability has been resolved:
x86/fpu: Invalidate FPU state after a failed XRSTOR from a user buffer
Both Intel and AMD consider it to be architecturally valid for XRSTOR to
fail with #PF but nonetheless change the register state. The actual
conditions under which this might occur are unclear [1], but it seems
plausible that this might be triggered if one sibling thread unmaps a page
and invalidates the shared TLB while another sibling thread is executing
XRSTOR on the page in question.
__fpu__restore_sig() can execute XRSTOR while the hardware registers
are preserved on behalf of a different victim task (using the
fpu_fpregs_owner_ctx mechanism), and, in theory, XRSTOR could fail but
modify the registers.
If this happens, then there is a window in which __fpu__restore_sig()
could schedule out and the victim task could schedule back in without
reloading its own FPU registers. This would result in part of the FPU
state that __fpu__restore_sig() was attempting to load leaking into the
victim task's user-visible state.
Invalidate preserved FPU registers on XRSTOR failure to prevent this
situation from corrupting any state.
[1] Frequent readers of the errata lists might imagine "complex
microarchitectural conditions".
Metrics
Affected Vendors & Products
References
History
Mon, 04 Nov 2024 12:15:00 +0000
Type | Values Removed | Values Added |
---|---|---|
Metrics |
ssvc
|
MITRE
Status: PUBLISHED
Assigner: Linux
Published: 2024-05-21T14:19:30.864Z
Updated: 2024-11-04T12:01:51.053Z
Reserved: 2024-04-10T18:59:19.529Z
Link: CVE-2021-47226
Vulnrichment
Updated: 2024-08-04T05:32:07.454Z
NVD
Status : Awaiting Analysis
Published: 2024-05-21T15:15:11.823
Modified: 2024-05-21T16:54:26.047
Link: CVE-2021-47226
Redhat