Linux/Unix 主機上安裝了一個或多個受到弱點影響的套件，且供應商未提供可用的修補程式。

  - 已解決 Linux 核心中的下列弱點：KVM: nVMX: Always make an attempt to map eVMCS after migration When enlightened VMCS is in use and nested state is migrated with vmx_get_nested_state()/vmx_set_nested_state() KVM can't map evmcs page right away: evmcs gpa is not 'struct kvm_vmx_nested_state_hdr' and we can't read it from VP assist page because userspace may decide to restore HV_X64_MSR_VP_ASSIST_PAGE after restoring nested state (and QEMU, for example, does exactly that).
    To make sure eVMCS is mapped /vmx_set_nested_state() raises KVM_REQ_GET_NESTED_STATE_PAGES request. Commit f2c7ef3ba955 (KVM: nSVM: cancel KVM_REQ_GET_NESTED_STATE_PAGES on nested vmexit) added KVM_REQ_GET_NESTED_STATE_PAGES clearing to nested_vmx_vmexit() to make sure MSR permission bitmap is not switched when an immediate exit from L2 to L1 happens right after migration (caused by a pending event, for example). Unfortunately, in the exact same situation we still need to have eVMCS mapped so nested_sync_vmcs12_to_shadow() reflects changes in VMCS12 to eVMCS. As a band-aid, restore nested_get_evmcs_page() when clearing KVM_REQ_GET_NESTED_STATE_PAGES in nested_vmx_vmexit(). The 'fix' is far from being ideal as we can't easily propagate possible failures and even if we could, this is most likely already too late to do so. The whole 'KVM_REQ_GET_NESTED_STATE_PAGES' idea for mapping eVMCS after migration seems to be fragile as we diverge too much from the 'native' path when vmptr loading happens on vmx_set_nested_state(). (CVE-2021-46978)

請注意，Nessus 依賴供應商報告的套件存在。

Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - 已修复 Linux 内核中的下列漏洞：KVM: nVMX: Always make an attempt to map eVMCS after migration When enlightened VMCS is in use and nested state is migrated with vmx_get_nested_state()/vmx_set_nested_state() KVM can't map evmcs page right away: evmcs gpa is not 'struct kvm_vmx_nested_state_hdr' and we can't read it from VP assist page because userspace may decide to restore HV_X64_MSR_VP_ASSIST_PAGE after restoring nested state (and QEMU, for example, does exactly that).
    To make sure eVMCS is mapped /vmx_set_nested_state() raises KVM_REQ_GET_NESTED_STATE_PAGES request. Commit f2c7ef3ba955 (KVM: nSVM: cancel KVM_REQ_GET_NESTED_STATE_PAGES on nested vmexit) added KVM_REQ_GET_NESTED_STATE_PAGES clearing to nested_vmx_vmexit() to make sure MSR permission bitmap is not switched when an immediate exit from L2 to L1 happens right after migration (caused by a pending event, for example). Unfortunately, in the exact same situation we still need to have eVMCS mapped so nested_sync_vmcs12_to_shadow() reflects changes in VMCS12 to eVMCS. As a band-aid, restore nested_get_evmcs_page() when clearing KVM_REQ_GET_NESTED_STATE_PAGES in nested_vmx_vmexit(). The 'fix' is far from being ideal as we can't easily propagate possible failures and even if we could, this is most likely already too late to do so. The whole 'KVM_REQ_GET_NESTED_STATE_PAGES' idea for mapping eVMCS after migration seems to be fragile as we diverge too much from the 'native' path when vmptr loading happens on vmx_set_nested_state(). (CVE-2021-46978)

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

Linux/Unix ホストには、ベンダーが提供するパッチが利用できない脆弱性の影響を受ける複数のパッケージがインストールされています。

  - Linux カーネルでは、以下の脆弱性が解決されています: KVM: nVMX: Always make an attempt to map eVMCS after migration When enlightened VMCS is in use and nested state is migrated with vmx_get_nested_state()/vmx_set_nested_state() KVM can't map evmcs page right away: evmcs gpa is not 'struct kvm_vmx_nested_state_hdr' and we can't read it from VP assist page because userspace may decide to restore HV_X64_MSR_VP_ASSIST_PAGE after restoring nested state (and QEMU, for example, does exactly that).
    To make sure eVMCS is mapped /vmx_set_nested_state() raises KVM_REQ_GET_NESTED_STATE_PAGES request. Commit f2c7ef3ba955 (KVM: nSVM: cancel KVM_REQ_GET_NESTED_STATE_PAGES on nested vmexit) added KVM_REQ_GET_NESTED_STATE_PAGES clearing to nested_vmx_vmexit() to make sure MSR permission bitmap is not switched when an immediate exit from L2 to L1 happens right after migration (caused by a pending event, for example). Unfortunately, in the exact same situation we still need to have eVMCS mapped so nested_sync_vmcs12_to_shadow() reflects changes in VMCS12 to eVMCS. As a band-aid, restore nested_get_evmcs_page() when clearing KVM_REQ_GET_NESTED_STATE_PAGES in nested_vmx_vmexit(). The 'fix' is far from being ideal as we can't easily propagate possible failures and even if we could, this is most likely already too late to do so. The whole 'KVM_REQ_GET_NESTED_STATE_PAGES' idea for mapping eVMCS after migration seems to be fragile as we diverge too much from the 'native' path when vmptr loading happens on vmx_set_nested_state(). (CVE-2021-46978)

Nessus は、ベンダーによって報告されたパッケージの存在に依存していることに注意してください。

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

    In the Linux kernel, the following vulnerability has been resolved:

    KVM: nVMX: Always make an attempt to map eVMCS after migration

    When enlightened VMCS is in use and nested state is migrated with     vmx_get_nested_state()/vmx_set_nested_state() KVM can't map evmcs     page right away: evmcs gpa is not 'struct kvm_vmx_nested_state_hdr'     and we can't read it from VP assist page because userspace may decide     to restore HV_X64_MSR_VP_ASSIST_PAGE after restoring nested state     (and QEMU, for example, does exactly that). To make sure eVMCS is     mapped /vmx_set_nested_state() raises KVM_REQ_GET_NESTED_STATE_PAGES     request.

    Commit f2c7ef3ba955 (KVM: nSVM: cancel KVM_REQ_GET_NESTED_STATE_PAGES     on nested vmexit) added KVM_REQ_GET_NESTED_STATE_PAGES clearing to     nested_vmx_vmexit() to make sure MSR permission bitmap is not switched     when an immediate exit from L2 to L1 happens right after migration (caused     by a pending event, for example). Unfortunately, in the exact same     situation we still need to have eVMCS mapped so     nested_sync_vmcs12_to_shadow() reflects changes in VMCS12 to eVMCS.

    As a band-aid, restore nested_get_evmcs_page() when clearing     KVM_REQ_GET_NESTED_STATE_PAGES in nested_vmx_vmexit(). The 'fix' is far     from being ideal as we can't easily propagate possible failures and even if     we could, this is most likely already too late to do so. The whole     'KVM_REQ_GET_NESTED_STATE_PAGES' idea for mapping eVMCS after migration     seems to be fragile as we diverge too much from the 'native' path when     vmptr loading happens on vmx_set_nested_state().

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.

  - In the Linux kernel, the following vulnerability has been resolved: KVM: nVMX: Always make an attempt to     map eVMCS after migration When enlightened VMCS is in use and nested state is migrated with     vmx_get_nested_state()/vmx_set_nested_state() KVM can't map evmcs page right away: evmcs gpa is not     'struct kvm_vmx_nested_state_hdr' and we can't read it from VP assist page because userspace may decide to     restore HV_X64_MSR_VP_ASSIST_PAGE after restoring nested state (and QEMU, for example, does exactly that).
    To make sure eVMCS is mapped /vmx_set_nested_state() raises KVM_REQ_GET_NESTED_STATE_PAGES request. Commit     f2c7ef3ba955 (KVM: nSVM: cancel KVM_REQ_GET_NESTED_STATE_PAGES on nested vmexit) added     KVM_REQ_GET_NESTED_STATE_PAGES clearing to nested_vmx_vmexit() to make sure MSR permission bitmap is not     switched when an immediate exit from L2 to L1 happens right after migration (caused by a pending event,     for example). Unfortunately, in the exact same situation we still need to have eVMCS mapped so     nested_sync_vmcs12_to_shadow() reflects changes in VMCS12 to eVMCS. As a band-aid, restore     nested_get_evmcs_page() when clearing KVM_REQ_GET_NESTED_STATE_PAGES in nested_vmx_vmexit(). The 'fix' is     far from being ideal as we can't easily propagate possible failures and even if we could, this is most     likely already too late to do so. The whole 'KVM_REQ_GET_NESTED_STATE_PAGES' idea for mapping eVMCS after     migration seems to be fragile as we diverge too much from the 'native' path when vmptr loading happens on     vmx_set_nested_state(). (CVE-2021-46978)

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

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

    In the Linux kernel, the following vulnerability has been resolved:

    KVM: nVMX: Always make an attempt to map eVMCS after migration

    When enlightened VMCS is in use and nested state is migrated with     vmx_get_nested_state()/vmx_set_nested_state() KVM can't map evmcs     page right away: evmcs gpa is not 'struct kvm_vmx_nested_state_hdr'     and we can't read it from VP assist page because userspace may decide     to restore HV_X64_MSR_VP_ASSIST_PAGE after restoring nested state     (and QEMU, for example, does exactly that). To make sure eVMCS is     mapped /vmx_set_nested_state() raises KVM_REQ_GET_NESTED_STATE_PAGES     request.

    Commit f2c7ef3ba955 (KVM: nSVM: cancel KVM_REQ_GET_NESTED_STATE_PAGES     on nested vmexit) added KVM_REQ_GET_NESTED_STATE_PAGES clearing to     nested_vmx_vmexit() to make sure MSR permission bitmap is not switched     when an immediate exit from L2 to L1 happens right after migration (caused     by a pending event, for example). Unfortunately, in the exact same     situation we still need to have eVMCS mapped so     nested_sync_vmcs12_to_shadow() reflects changes in VMCS12 to eVMCS.

    As a band-aid, restore nested_get_evmcs_page() when clearing     KVM_REQ_GET_NESTED_STATE_PAGES in nested_vmx_vmexit(). The 'fix' is far     from being ideal as we can't easily propagate possible failures and even if     we could, this is most likely already too late to do so. The whole     'KVM_REQ_GET_NESTED_STATE_PAGES' idea for mapping eVMCS after migration     seems to be fragile as we diverge too much from the 'native' path when     vmptr loading happens on vmx_set_nested_state().

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.

ID	Name	Product	Family	Published	Updated	Severity
160459	Amazon Linux 2 内核 --advisory ALAS2KERNEL-5。10-2022-002 (ALASKERNEL-5.10-2022-002)	Nessus	Amazon Linux Local Security Checks	5/2/2022	2/9/2026	high
160459	Amazon Linux 2核心 --advisory ALAS2KERNEL-5。10-2022-002 (ALASKERNEL-5.10-2022-002)	Nessus	Amazon Linux Local Security Checks	5/2/2022	2/9/2026	high
229765	Linux Distros 未修補的弱點：CVE-2021-46978	Nessus	Misc.	3/5/2025	7/17/2026	high
229765	Linux Distros 未修补的漏洞：CVE-2021-46978	Nessus	Misc.	3/5/2025	7/17/2026	high
160459	Amazon Linux 2kernel、 --advisory ALAS2KERNEL-5。10-2022-002 ALASKERNEL-5.10-2022-002	Nessus	Amazon Linux Local Security Checks	5/2/2022	2/9/2026	high
229765	Linux Distros のパッチ未適用の脆弱性: CVE-2021-46978	Nessus	Misc.	3/5/2025	7/17/2026	high
273512	Unity Linux 20.1070a Security Update: kernel (UTSA-2025-988997)	Nessus	Unity Linux Local Security Checks	11/5/2025	11/5/2025	high
160459	Amazon Linux 2 : kernel, --advisory ALAS2KERNEL-5.10-2022-002 (ALASKERNEL-5.10-2022-002)	Nessus	Amazon Linux Local Security Checks	5/2/2022	2/9/2026	high
229765	Linux Distros Unpatched Vulnerability : CVE-2021-46978	Nessus	Misc.	3/5/2025	7/17/2026	high
239060	TencentOS Server 4: kernel (TSSA-2024:0958)	Nessus	Tencent Local Security Checks	6/16/2025	11/23/2025	high
268633	Unity Linux 20.1070e Security Update: kernel (UTSA-2025-987000)	Nessus	Unity Linux Local Security Checks	10/7/2025	10/15/2025	high

Detections

Analytics

Plugins Search

high

high

high

high

high

high

high

high

high

high

high