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 CentOS Linux 8.4 host has packages installed that are affected by multiple vulnerabilities as referenced in the TuxCare CENTOS8.4:CLSA-2026:1782145985 advisory.

  - Linux kernel CIFS implementation, version 4.9.0 is vulnerable to a relative paths injection in directory     entry lists. (CVE-2019-10220)

  - An issue was discovered in write_tpt_entry in drivers/infiniband/hw/cxgb4/mem.c in the Linux kernel     through 5.3.2. The cxgb4 driver is directly calling dma_map_single (a DMA function) from a stack variable.
    This could allow an attacker to trigger a Denial of Service, exploitable if this driver is used on an     architecture for which this stack/DMA interaction has security relevance. (CVE-2019-17075)

  - The KVM implementation in the Linux kernel through 4.20.5 has a Use-after-Free. (CVE-2019-7221)

  - This vulnerability allows local attackers to escalate privileges on affected installations of Linux Kernel     5.14-rc3. An attacker must first obtain the ability to execute low-privileged code on the target system in     order to exploit this vulnerability. The specific flaw exists within the handling of eBPF programs. The     issue results from the lack of proper validation of user-supplied eBPF programs, which can result in a     type confusion condition. An attacker can leverage this vulnerability to escalate privileges and execute     arbitrary code in the context of the kernel. Was ZDI-CAN-14689. (CVE-2021-34866)

  - In the Linux kernel, the following vulnerability has been resolved: kyber: fix out of bounds access when     preempted __blk_mq_sched_bio_merge() gets the ctx and hctx for the current CPU and passes the hctx to
    ->bio_merge(). kyber_bio_merge() then gets the ctx for the current CPU again and uses that to get the     corresponding Kyber context in the passed hctx. However, the thread may be preempted between the two calls     to blk_mq_get_ctx(), and the ctx returned the second time may no longer correspond to the passed hctx.
    This works accidentally most of the time, but it can cause us to read garbage if the second ctx came     from an hctx with more ctx's than the first one (i.e., if ctx->index_hw[hctx->type] > hctx->nr_ctx). This     manifested as this UBSAN array index out of bounds error reported by Jakub: UBSAN: array-index-out-of-     bounds in ../kernel/locking/qspinlock.c:130:9 index 13106 is out of range for type 'long unsigned int     [128]' Call Trace: dump_stack+0xa4/0xe5 ubsan_epilogue+0x5/0x40
    __ubsan_handle_out_of_bounds.cold.13+0x2a/0x34 queued_spin_lock_slowpath+0x476/0x480     do_raw_spin_lock+0x1c2/0x1d0 kyber_bio_merge+0x112/0x180 blk_mq_submit_bio+0x1f5/0x1100     submit_bio_noacct+0x7b0/0x870 submit_bio+0xc2/0x3a0 btrfs_map_bio+0x4f0/0x9d0     btrfs_submit_data_bio+0x24e/0x310 submit_one_bio+0x7f/0xb0 submit_extent_page+0xc4/0x440
    __extent_writepage_io+0x2b8/0x5e0 __extent_writepage+0x28d/0x6e0 extent_write_cache_pages+0x4d7/0x7a0     extent_writepages+0xa2/0x110 do_writepages+0x8f/0x180 __writeback_single_inode+0x99/0x7f0     writeback_sb_inodes+0x34e/0x790 __writeback_inodes_wb+0x9e/0x120 wb_writeback+0x4d2/0x660     wb_workfn+0x64d/0xa10 process_one_work+0x53a/0xa80 worker_thread+0x69/0x5b0 kthread+0x20b/0x240     ret_from_fork+0x1f/0x30 Only Kyber uses the hctx, so fix it by passing the request_queue to ->bio_merge()     instead. BFQ and mq-deadline just use that, and Kyber can map the queues itself to avoid the mismatch.
    (CVE-2021-46984)

Note that Nessus has not tested for these issues 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-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.

  - Red Hat Enterprise Linux - kernel: x86/fpu: Invalidate FPU state after a failed XRSTOR from a user buffer     Ubuntu Linux - 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	Type	Severity
360976	CentOS Linux 8.4 [TuxCare] Security Update: bpftool / kernel / kernel-core / kernel-cross-headers / etc Multiple Vulnerabilities (CENTOS8.4:CLSA-2026:1782145985)	Nessus	CentOS Local Security Checks	Local	high
272898	Unity Linux 20.1070a Security Update: kernel (UTSA-2025-988697)	Nessus	Unity Linux Local Security Checks	Local	high
268774	Unity Linux 20.1070e Security Update: kernel (UTSA-2025-987393)	Nessus	Unity Linux Local Security Checks	Local	high
239342	TencentOS Server 4: kernel (TSSA-2024:0981)	Nessus	Tencent Local Security Checks	Local	high
229762	Linux Distros Unpatched Vulnerability : CVE-2021-47226	Nessus	Misc.	Local	high
160459	Amazon Linux 2 : kernel, --advisory ALAS2KERNEL-5.10-2022-002 (ALASKERNEL-5.10-2022-002)	Nessus	Amazon Linux Local Security Checks	Local	high

Detections

Analytics

CVE-2021-47226

high

Tenable Plugins

high

high

high

high

high

high