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".

The Unity Linux 20 host has a package installed that is affected by a vulnerability as referenced in the UTSA-2025-988697 advisory.

    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.

Tenable has extracted the preceding description block directly from the Unity Linux security advisory.

Note that Nessus has not tested for this issue but has instead relied only on the application's self-reported version number.

The Unity Linux 20 host has a package installed that is affected by a vulnerability as referenced in the UTSA-2025-987393 advisory.

    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.

Tenable has extracted the preceding description block directly from the Unity Linux security advisory.

Note that Nessus has not tested for this issue but has instead relied only on the application's self-reported version number.

The Linux/Unix host has one or more packages installed that are impacted by a vulnerability without a vendor supplied patch available.

  - 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. (CVE-2021-47226)

Note that Nessus relies on the presence of the package as reported by the vendor.

ID	Name	Product	Family	Severity
272898	Unity Linux 20.1070a Security Update: kernel (UTSA-2025-988697)	Nessus	Unity Linux Local Security Checks	high
268774	Unity Linux 20.1070e Security Update: kernel (UTSA-2025-987393)	Nessus	Unity Linux Local Security Checks	high
239342	TencentOS Server 4: kernel (TSSA-2024:0981)	Nessus	Tencent Local Security Checks	high
229762	Linux Distros Unpatched Vulnerability : CVE-2021-47226	Nessus	Misc.	high
160459	Amazon Linux 2 : kernel, --advisory ALAS2KERNEL-5.10-2022-002 (ALASKERNEL-5.10-2022-002)	Nessus	Amazon Linux Local Security Checks	high

Detections

Analytics

CVE-2021-47226

high

Tenable Plugins

high

high

high

high

high