CVE-2021-47226
published 2024-05-21CVE-2021-47226: 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…
PriorityP428high7.1CVSS 3.1
AVLACLPRLUINSUCNIHAH
EPSS
0.22%
12.9th percentile
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".
Affected
17 ranges
| Vendor | Product | Version range | Fixed in |
|---|---|---|---|
| debian | linux | < linux 5.10.46-1 (bookworm) | linux 5.10.46-1 (bookworm) |
| linux | linux | — | — |
| linux | linux | >= 1d731e731c4cd7cbd3b1aa295f0932e7610da82f < a7748e021b9fb7739e3cb88449296539de0b6817 | a7748e021b9fb7739e3cb88449296539de0b6817 |
| linux | linux | >= 1d731e731c4cd7cbd3b1aa295f0932e7610da82f < 002665dcba4bbec8c82f0aeb4bd3f44334ed2c14 | 002665dcba4bbec8c82f0aeb4bd3f44334ed2c14 |
| linux | linux | >= 1d731e731c4cd7cbd3b1aa295f0932e7610da82f < d8778e393afa421f1f117471144f8ce6deb6953a | d8778e393afa421f1f117471144f8ce6deb6953a |
| linux | linux_kernel | — | — |
| linux | linux_kernel | — | — |
| linux | linux_kernel | — | — |
| linux | linux_kernel | — | — |
| linux | linux_kernel | — | — |
| linux | linux_kernel | — | — |
| linux | linux_kernel | >= 0 < 5.10.46-1 | 5.10.46-1 |
| linux | linux_kernel | >= 0 < 5.10.46-1 | 5.10.46-1 |
| linux | linux_kernel | >= 0 < 5.10.46-1 | 5.10.46-1 |
| linux | linux_kernel | >= 0 < 5.10.46-1 | 5.10.46-1 |
| linux | linux_kernel | >= 5.11 < 5.12.13 | 5.12.13 |
| linux | linux_kernel | >= 5.2 < 5.10.46 | 5.10.46 |
CVSS provenance
nvdv3.17.1HIGHCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H
osv7.1HIGH
vendor_debian7.1HIGH
vendor_redhat7.1HIGH
Stop checking back — get the weekly exploitation signal.
Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.
GHSA
GHSA-4jxh-jrgp-4422: In the Linux kernel, the following vulnerability has been resolved:
x86/fpu: Invalidate FPU state after a failed XRSTOR from a user buffer
Both Inte
ghsa_unreviewed·2024-05-21
CVE-2021-47226 [HIGH] CWE-203 GHSA-4jxh-jrgp-4422: In the Linux kernel, the following vulnerability has been resolved:
x86/fpu: Invalidate FPU state after a failed XRSTOR from a user buffer
Both Inte
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
OSV
CVE-2021-47226: 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
osv·2024-05-21·CVSS 7.1
CVE-2021-47226 [HIGH] CVE-2021-47226: 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
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 whi
Red Hat
kernel: x86/fpu: Invalidate FPU state after a failed XRSTOR from a user buffer
vendor_redhat·2024-05-21·CVSS 7.1
CVE-2021-47226 [HIGH] CWE-402 kernel: x86/fpu: Invalidate FPU state after a failed XRSTOR from a user buffer
kernel: x86/fpu: Invalidate FPU state after a failed XRSTOR from a user buffer
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 cou
Debian
CVE-2021-47226: linux - In the Linux kernel, the following vulnerability has been resolved: x86/fpu: In...
vendor_debian·2021·CVSS 7.1
CVE-2021-47226 [HIGH] CVE-2021-47226: linux - In the Linux kernel, the following vulnerability has been resolved: x86/fpu: In...
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 whi
No detection rules found.
No public exploits indexed.
https://git.kernel.org/stable/c/002665dcba4bbec8c82f0aeb4bd3f44334ed2c14https://git.kernel.org/stable/c/a7748e021b9fb7739e3cb88449296539de0b6817https://git.kernel.org/stable/c/d8778e393afa421f1f117471144f8ce6deb6953ahttps://git.kernel.org/stable/c/002665dcba4bbec8c82f0aeb4bd3f44334ed2c14https://git.kernel.org/stable/c/a7748e021b9fb7739e3cb88449296539de0b6817https://git.kernel.org/stable/c/d8778e393afa421f1f117471144f8ce6deb6953a
2024-05-21
Published