IOMMU: RMRR (VT-d) and unity map (AMD-Vi) handling issues T[his CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] Certain PCI devices in a system might be assigned Reserved Memory Regions (specified via Reserved Memory Region Reporting, "RMRR") for Intel VT-d or Unity Mapping ranges for AMD-Vi. These are typically used for platform tasks such as legacy USB emulation. Since the precise purpose of these regions is unknown, once a device associated with such a region is active, the mappings of these regions need to remain continuouly accessible by the device. This requirement has been violated. Subsequent DMA or interrupts from the device may have unpredictable behaviour, ranging from IOMMU faults to memory corruption.

There are packages installed that are affected by multiple vulnerabilities referenced in the following CVEs:

  - race in VT-d domain ID cleanup Xen domain IDs are up to 15 bits wide. VT-d hardware may allow for only
    less than 15 bits to hold a domain ID associating a physical device with a particular domain. Therefore
    internally Xen domain IDs are mapped to the smaller value range. The cleaning up of the housekeeping
    structures has a race, allowing for VT-d domain IDs to be leaked and flushes to be bypassed.
    (CVE-2022-26357)

  - LFENCE/JMP (mitigation V2-2) may not sufficiently mitigate CVE-2017-5715 on some AMD CPUs.
    (CVE-2021-26401)

  - Incomplete cleanup of multi-core shared buffers for some Intel(R) Processors may allow an authenticated
    user to potentially enable information disclosure via local access. (CVE-2022-21123)

  - Incomplete cleanup of microarchitectural fill buffers on some Intel(R) Processors may allow an
    authenticated user to potentially enable information disclosure via local access. (CVE-2022-21125)

  - Incomplete cleanup in specific special register write operations for some Intel(R) Processors may allow an
    authenticated user to potentially enable information disclosure via local access. (CVE-2022-21166)

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

  - IOMMU: RMRR (VT-d) and unity map (AMD-Vi) handling issues T[his CNA information record relates to multiple     CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] Certain PCI devices in a     system might be assigned Reserved Memory Regions (specified via Reserved Memory Region Reporting, RMRR)     for Intel VT-d or Unity Mapping ranges for AMD-Vi. These are typically used for platform tasks such as     legacy USB emulation. Since the precise purpose of these regions is unknown, once a device associated with     such a region is active, the mappings of these regions need to remain continuouly accessible by the     device. This requirement has been violated. Subsequent DMA or interrupts from the device may have     unpredictable behaviour, ranging from IOMMU faults to memory corruption. (CVE-2022-26360)

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

There are packages installed that are affected by multiple vulnerabilities referenced in the following CVEs:

  - race in VT-d domain ID cleanup Xen domain IDs are up to 15 bits wide. VT-d hardware may allow for only
    less than 15 bits to hold a domain ID associating a physical device with a particular domain. Therefore
    internally Xen domain IDs are mapped to the smaller value range. The cleaning up of the housekeeping
    structures has a race, allowing for VT-d domain IDs to be leaked and flushes to be bypassed.
    (CVE-2022-26357)

  - arm: guest_physmap_remove_page not removing the p2m mappings The functions to remove one or more entries
    from a guest p2m pagetable on Arm (p2m_remove_mapping, guest_physmap_remove_page, and p2m_set_entry with
    mfn set to INVALID_MFN) do not actually clear the pagetable entry if the entry doesn't have the valid bit
    set. It is possible to have a valid pagetable entry without the valid bit set when a guest operating
    system uses set/way cache maintenance instructions. For instance, a guest issuing a set/way cache
    maintenance instruction, then calling the XENMEM_decrease_reservation hypercall to give back memory pages
    to Xen, might be able to retain access to those pages even after Xen started reusing them for other
    purposes. (CVE-2022-23033)

  - A PV guest could DoS Xen while unmapping a grant To address XSA-380, reference counting was introduced for
    grant mappings for the case where a PV guest would have the IOMMU enabled. PV guests can request two forms
    of mappings. When both are in use for any individual mapping, unmapping of such a mapping can be requested
    in two steps. The reference count for such a mapping would then mistakenly be decremented twice. Underflow
    of the counters gets detected, resulting in the triggering of a hypervisor bug check. (CVE-2022-23034)

  - Insufficient cleanup of passed-through device IRQs The management of IRQs associated with physical devices
    exposed to x86 HVM guests involves an iterative operation in particular when cleaning up after the guest's
    use of the device. In the case where an interrupt is not quiescent yet at the time this cleanup gets
    invoked, the cleanup attempt may be scheduled to be retried. When multiple interrupts are involved, this
    scheduling of a retry may get erroneously skipped. At the same time pointers may get cleared (resulting in
    a de-reference of NULL) and freed (resulting in a use-after-free), while other code would continue to
    assume them to be valid. (CVE-2022-23035)

  - Racy interactions between dirty vram tracking and paging log dirty hypercalls Activation of log dirty mode
    done by XEN_DMOP_track_dirty_vram (was named HVMOP_track_dirty_vram before Xen 4.9) is racy with ongoing
    log dirty hypercalls. A suitably timed call to XEN_DMOP_track_dirty_vram can enable log dirty while
    another CPU is still in the process of tearing down the structures related to a previously enabled log
    dirty mode (XEN_DOMCTL_SHADOW_OP_OFF). This is due to lack of mutually exclusive locking between both
    operations and can lead to entries being added in already freed slots, resulting in a memory leak.
    (CVE-2022-26356)

The remote host is affected by the vulnerability described in GLSA-202402-07 (Xen: Multiple Vulnerabilities)

    Multiple vulnerabilities have been discovered in Xen. Please review the CVE identifiers referenced below     for details.

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

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

There are packages installed that are affected by multiple vulnerabilities referenced in the following CVEs:

  - grant table v2 status pages may remain accessible after de-allocation (take two) Guest get permitted
    access to certain Xen-owned pages of memory. The majority of such pages remain allocated / associated with
    a guest for its entire lifetime. Grant table v2 status pages, however, get de-allocated when a guest
    switched (back) from v2 to v1. The freeing of such pages requires that the hypervisor know where in the
    guest these pages were mapped. The hypervisor tracks only one use within guest space, but racing requests
    from the guest to insert mappings of these pages may result in any of them to become mapped in multiple
    locations. Upon switching back from v2 to v1, the guest would then retain access to a page that was freed
    and perhaps re-used for other purposes. This bug was fortuitously fixed by code cleanup in Xen 4.14, and
    backported to security-supported Xen branches as a prerequisite of the fix for XSA-378. (CVE-2021-28703)

  - guests may exceed their designated memory limit When a guest is permitted to have close to 16TiB of
    memory, it may be able to issue hypercalls to increase its memory allocation beyond the administrator
    established limit. This is a result of a calculation done with 32-bit precision, which may overflow. It
    would then only be the overflowed (and hence small) number which gets compared against the established
    upper bound. (CVE-2021-28706)

  - arm: guest_physmap_remove_page not removing the p2m mappings The functions to remove one or more entries
    from a guest p2m pagetable on Arm (p2m_remove_mapping, guest_physmap_remove_page, and p2m_set_entry with
    mfn set to INVALID_MFN) do not actually clear the pagetable entry if the entry doesn't have the valid bit
    set. It is possible to have a valid pagetable entry without the valid bit set when a guest operating
    system uses set/way cache maintenance instructions. For instance, a guest issuing a set/way cache
    maintenance instruction, then calling the XENMEM_decrease_reservation hypercall to give back memory pages
    to Xen, might be able to retain access to those pages even after Xen started reusing them for other
    purposes. (CVE-2022-23033)

  - A PV guest could DoS Xen while unmapping a grant To address XSA-380, reference counting was introduced for
    grant mappings for the case where a PV guest would have the IOMMU enabled. PV guests can request two forms
    of mappings. When both are in use for any individual mapping, unmapping of such a mapping can be requested
    in two steps. The reference count for such a mapping would then mistakenly be decremented twice. Underflow
    of the counters gets detected, resulting in the triggering of a hypervisor bug check. (CVE-2022-23034)

There are packages installed that are affected by multiple vulnerabilities referenced in the following CVEs:

  - race in VT-d domain ID cleanup Xen domain IDs are up to 15 bits wide. VT-d hardware may allow for only
    less than 15 bits to hold a domain ID associating a physical device with a particular domain. Therefore
    internally Xen domain IDs are mapped to the smaller value range. The cleaning up of the housekeeping
    structures has a race, allowing for VT-d domain IDs to be leaked and flushes to be bypassed.
    (CVE-2022-26357)

  - guests may exceed their designated memory limit When a guest is permitted to have close to 16TiB of
    memory, it may be able to issue hypercalls to increase its memory allocation beyond the administrator
    established limit. This is a result of a calculation done with 32-bit precision, which may overflow. It
    would then only be the overflowed (and hence small) number which gets compared against the established
    upper bound. (CVE-2021-28706)

  - arm: guest_physmap_remove_page not removing the p2m mappings The functions to remove one or more entries
    from a guest p2m pagetable on Arm (p2m_remove_mapping, guest_physmap_remove_page, and p2m_set_entry with
    mfn set to INVALID_MFN) do not actually clear the pagetable entry if the entry doesn't have the valid bit
    set. It is possible to have a valid pagetable entry without the valid bit set when a guest operating
    system uses set/way cache maintenance instructions. For instance, a guest issuing a set/way cache
    maintenance instruction, then calling the XENMEM_decrease_reservation hypercall to give back memory pages
    to Xen, might be able to retain access to those pages even after Xen started reusing them for other
    purposes. (CVE-2022-23033)

  - A PV guest could DoS Xen while unmapping a grant To address XSA-380, reference counting was introduced for
    grant mappings for the case where a PV guest would have the IOMMU enabled. PV guests can request two forms
    of mappings. When both are in use for any individual mapping, unmapping of such a mapping can be requested
    in two steps. The reference count for such a mapping would then mistakenly be decremented twice. Underflow
    of the counters gets detected, resulting in the triggering of a hypervisor bug check. (CVE-2022-23034)

  - Insufficient cleanup of passed-through device IRQs The management of IRQs associated with physical devices
    exposed to x86 HVM guests involves an iterative operation in particular when cleaning up after the guest's
    use of the device. In the case where an interrupt is not quiescent yet at the time this cleanup gets
    invoked, the cleanup attempt may be scheduled to be retried. When multiple interrupts are involved, this
    scheduling of a retry may get erroneously skipped. At the same time pointers may get cleared (resulting in
    a de-reference of NULL) and freed (resulting in a use-after-free), while other code would continue to
    assume them to be valid. (CVE-2022-23035)

The remote SUSE Linux SLES15 / SLES_SAP15 host has packages installed that are affected by multiple vulnerabilities as referenced in the SUSE-SU-2022:2158-1 advisory.

  - Racy interactions between dirty vram tracking and paging log dirty hypercalls Activation of log dirty mode     done by XEN_DMOP_track_dirty_vram (was named HVMOP_track_dirty_vram before Xen 4.9) is racy with ongoing     log dirty hypercalls. A suitably timed call to XEN_DMOP_track_dirty_vram can enable log dirty while     another CPU is still in the process of tearing down the structures related to a previously enabled log     dirty mode (XEN_DOMCTL_SHADOW_OP_OFF). This is due to lack of mutually exclusive locking between both     operations and can lead to entries being added in already freed slots, resulting in a memory leak.
    (CVE-2022-26356)

  - race in VT-d domain ID cleanup Xen domain IDs are up to 15 bits wide. VT-d hardware may allow for only     less than 15 bits to hold a domain ID associating a physical device with a particular domain. Therefore     internally Xen domain IDs are mapped to the smaller value range. The cleaning up of the housekeeping     structures has a race, allowing for VT-d domain IDs to be leaked and flushes to be bypassed.
    (CVE-2022-26357)

  - IOMMU: RMRR (VT-d) and unity map (AMD-Vi) handling issues T[his CNA information record relates to multiple     CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] Certain PCI devices in a     system might be assigned Reserved Memory Regions (specified via Reserved Memory Region Reporting, RMRR)     for Intel VT-d or Unity Mapping ranges for AMD-Vi. These are typically used for platform tasks such as     legacy USB emulation. Since the precise purpose of these regions is unknown, once a device associated with     such a region is active, the mappings of these regions need to remain continuouly accessible by the     device. This requirement has been violated. Subsequent DMA or interrupts from the device may have     unpredictable behaviour, ranging from IOMMU faults to memory corruption. (CVE-2022-26358, CVE-2022-26359,     CVE-2022-26360, CVE-2022-26361)

  - x86 pv: Race condition in typeref acquisition Xen maintains a type reference count for pages, in addition     to a regular reference count. This scheme is used to maintain invariants required for Xen's safety, e.g.
    PV guests may not have direct writeable access to pagetables; updates need auditing by Xen. Unfortunately,     the logic for acquiring a type reference has a race condition, whereby a safely TLB flush is issued too     early and creates a window where the guest can re-establish the read/write mapping before writeability is     prohibited. (CVE-2022-26362)

  - x86 pv: Insufficient care with non-coherent mappings T[his CNA information record relates to multiple     CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] Xen maintains a type     reference count for pages, in addition to a regular reference count. This scheme is used to maintain     invariants required for Xen's safety, e.g. PV guests may not have direct writeable access to pagetables;
    updates need auditing by Xen. Unfortunately, Xen's safety logic doesn't account for CPU-induced cache non-     coherency; cases where the CPU can cause the content of the cache to be different to the content in main     memory. In such cases, Xen's safety logic can incorrectly conclude that the contents of a page is safe.
    (CVE-2022-26363, CVE-2022-26364)

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

The remote SUSE Linux SLED15 / SLED_SAP15 / SLES15 / SLES_SAP15 host has packages installed that are affected by multiple vulnerabilities as referenced in the SUSE-SU-2022:2065-1 advisory.

  - IOMMU: RMRR (VT-d) and unity map (AMD-Vi) handling issues T[his CNA information record relates to multiple     CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] Certain PCI devices in a     system might be assigned Reserved Memory Regions (specified via Reserved Memory Region Reporting, RMRR)     for Intel VT-d or Unity Mapping ranges for AMD-Vi. These are typically used for platform tasks such as     legacy USB emulation. Since the precise purpose of these regions is unknown, once a device associated with     such a region is active, the mappings of these regions need to remain continuouly accessible by the     device. This requirement has been violated. Subsequent DMA or interrupts from the device may have     unpredictable behaviour, ranging from IOMMU faults to memory corruption. (CVE-2022-26358, CVE-2022-26359,     CVE-2022-26360, CVE-2022-26361)

  - x86 pv: Race condition in typeref acquisition Xen maintains a type reference count for pages, in addition     to a regular reference count. This scheme is used to maintain invariants required for Xen's safety, e.g.
    PV guests may not have direct writeable access to pagetables; updates need auditing by Xen. Unfortunately,     the logic for acquiring a type reference has a race condition, whereby a safely TLB flush is issued too     early and creates a window where the guest can re-establish the read/write mapping before writeability is     prohibited. (CVE-2022-26362)

  - x86 pv: Insufficient care with non-coherent mappings T[his CNA information record relates to multiple     CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] Xen maintains a type     reference count for pages, in addition to a regular reference count. This scheme is used to maintain     invariants required for Xen's safety, e.g. PV guests may not have direct writeable access to pagetables;
    updates need auditing by Xen. Unfortunately, Xen's safety logic doesn't account for CPU-induced cache non-     coherency; cases where the CPU can cause the content of the cache to be different to the content in main     memory. In such cases, Xen's safety logic can incorrectly conclude that the contents of a page is safe.
    (CVE-2022-26363, CVE-2022-26364)

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

The remote SUSE Linux SLED15 / SLED_SAP15 / SLES15 / SLES_SAP15 / openSUSE 15 host has packages installed that are affected by multiple vulnerabilities as referenced in the SUSE-SU-2022:1506-1 advisory.

    - CVE-2022-26356: Fixed potential race conditions in dirty memory tracking that       could cause a denial of service in the host (bsc#1197423).
    - CVE-2022-26357: Fixed a potential race condition in memory cleanup for hosts       using VT-d IOMMU hardware, which could lead to a denial of service in the host       (bsc#1197425).
    - CVE-2022-26358,CVE-2022-26359,CVE-2022-26360,CVE-2022-26361: Fixed various memory       corruption issues for hosts using VT-d or AMD-Vi IOMMU hardware. These could be       leveraged by an attacker to cause a denial of service in the host (bsc#1197426).

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

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

The remote SUSE Linux SLES12 / SLES_SAP12 host has packages installed that are affected by multiple vulnerabilities as referenced in the SUSE-SU-2022:1505-1 advisory.

  - Racy interactions between dirty vram tracking and paging log dirty hypercalls Activation of log dirty mode     done by XEN_DMOP_track_dirty_vram (was named HVMOP_track_dirty_vram before Xen 4.9) is racy with ongoing     log dirty hypercalls. A suitably timed call to XEN_DMOP_track_dirty_vram can enable log dirty while     another CPU is still in the process of tearing down the structures related to a previously enabled log     dirty mode (XEN_DOMCTL_SHADOW_OP_OFF). This is due to lack of mutually exclusive locking between both     operations and can lead to entries being added in already freed slots, resulting in a memory leak.
    (CVE-2022-26356)

  - race in VT-d domain ID cleanup Xen domain IDs are up to 15 bits wide. VT-d hardware may allow for only     less than 15 bits to hold a domain ID associating a physical device with a particular domain. Therefore     internally Xen domain IDs are mapped to the smaller value range. The cleaning up of the housekeeping     structures has a race, allowing for VT-d domain IDs to be leaked and flushes to be bypassed.
    (CVE-2022-26357)

  - IOMMU: RMRR (VT-d) and unity map (AMD-Vi) handling issues T[his CNA information record relates to multiple     CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] Certain PCI devices in a     system might be assigned Reserved Memory Regions (specified via Reserved Memory Region Reporting, RMRR)     for Intel VT-d or Unity Mapping ranges for AMD-Vi. These are typically used for platform tasks such as     legacy USB emulation. Since the precise purpose of these regions is unknown, once a device associated with     such a region is active, the mappings of these regions need to remain continuouly accessible by the     device. This requirement has been violated. Subsequent DMA or interrupts from the device may have     unpredictable behaviour, ranging from IOMMU faults to memory corruption. (CVE-2022-26358, CVE-2022-26359,     CVE-2022-26360, CVE-2022-26361)

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

The remote SUSE Linux SLES12 / SLES_SAP12 host has packages installed that are affected by multiple vulnerabilities as referenced in the SUSE-SU-2022:1408-1 advisory.

    - CVE-2022-26356: Fixed potential race conditions in dirty memory tracking that       could cause a denial of service in the host (bsc#1197423).
    - CVE-2022-26357: Fixed a potential race condition in memory cleanup for hosts       using VT-d IOMMU hardware, which could lead to a denial of service in the host       (bsc#1197425).
    - CVE-2022-26358,CVE-2022-26359,CVE-2022-26360,CVE-2022-26361: Fixed various memory       corruption issues for hosts using VT-d or AMD-Vi IOMMU hardware. These could be       leveraged by an attacker to cause a denial of service in the host (bsc#1197426).
    - CVE-2022-0001, CVE-2022-0002, CVE-2021-26401: Added BHB speculation issue       mitigations (bsc#1196915).

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

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

The remote SUSE Linux SLES15 / SLES_SAP15 host has packages installed that are affected by multiple vulnerabilities as referenced in the SUSE-SU-2022:1359-1 advisory.

    - CVE-2022-26356: Fixed potential race conditions in dirty memory tracking that       could cause a denial of service in the host (bsc#1197423).
    - CVE-2022-26357: Fixed a potential race condition in memory cleanup for hosts       using VT-d IOMMU hardware, which could lead to a denial of service in the host       (bsc#1197425).
    - CVE-2022-26358,CVE-2022-26359,CVE-2022-26360,CVE-2022-26361: Fixed various memory       corruption issues for hosts using VT-d or AMD-Vi IOMMU hardware. These could be       leveraged by an attacker to cause a denial of service in the host (bsc#1197426).
    - CVE-2022-0001, CVE-2022-0002, CVE-2021-26401: Added BHB speculation issue       mitigations (bsc#1196915).

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

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

The remote SUSE Linux SLES12 host has packages installed that are affected by multiple vulnerabilities as referenced in the SUSE-SU-2022:1375-1 advisory.

  - An infinite loop flaw was found in the e1000 NIC emulator of the QEMU. This issue occurs while processing     transmits (tx) descriptors in process_tx_desc if various descriptor fields are initialized with invalid     values. This flaw allows a guest to consume CPU cycles on the host, resulting in a denial of service. The     highest threat from this vulnerability is to system availability. (CVE-2021-20257)

  - LFENCE/JMP (mitigation V2-2) may not sufficiently mitigate CVE-2017-5715 on some AMD CPUs.
    (CVE-2021-26401)

  - Non-transparent sharing of branch predictor selectors between contexts in some Intel(R) Processors may     allow an authorized user to potentially enable information disclosure via local access. (CVE-2022-0001)

  - Non-transparent sharing of branch predictor within a context in some Intel(R) Processors may allow an     authorized user to potentially enable information disclosure via local access. (CVE-2022-0002)

  - Racy interactions between dirty vram tracking and paging log dirty hypercalls Activation of log dirty mode     done by XEN_DMOP_track_dirty_vram (was named HVMOP_track_dirty_vram before Xen 4.9) is racy with ongoing     log dirty hypercalls. A suitably timed call to XEN_DMOP_track_dirty_vram can enable log dirty while     another CPU is still in the process of tearing down the structures related to a previously enabled log     dirty mode (XEN_DOMCTL_SHADOW_OP_OFF). This is due to lack of mutually exclusive locking between both     operations and can lead to entries being added in already freed slots, resulting in a memory leak.
    (CVE-2022-26356)

  - race in VT-d domain ID cleanup Xen domain IDs are up to 15 bits wide. VT-d hardware may allow for only     less than 15 bits to hold a domain ID associating a physical device with a particular domain. Therefore     internally Xen domain IDs are mapped to the smaller value range. The cleaning up of the housekeeping     structures has a race, allowing for VT-d domain IDs to be leaked and flushes to be bypassed.
    (CVE-2022-26357)

  - IOMMU: RMRR (VT-d) and unity map (AMD-Vi) handling issues T[his CNA information record relates to multiple     CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] Certain PCI devices in a     system might be assigned Reserved Memory Regions (specified via Reserved Memory Region Reporting, RMRR)     for Intel VT-d or Unity Mapping ranges for AMD-Vi. These are typically used for platform tasks such as     legacy USB emulation. Since the precise purpose of these regions is unknown, once a device associated with     such a region is active, the mappings of these regions need to remain continuouly accessible by the     device. This requirement has been violated. Subsequent DMA or interrupts from the device may have     unpredictable behaviour, ranging from IOMMU faults to memory corruption. (CVE-2022-26358, CVE-2022-26359,     CVE-2022-26360, CVE-2022-26361)

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

The remote SUSE Linux SLES15 / SLES_SAP15 host has packages installed that are affected by multiple vulnerabilities as referenced in the SUSE-SU-2022:1300-1 advisory.

  - LFENCE/JMP (mitigation V2-2) may not sufficiently mitigate CVE-2017-5715 on some AMD CPUs.
    (CVE-2021-26401)

  - Non-transparent sharing of branch predictor selectors between contexts in some Intel(R) Processors may     allow an authorized user to potentially enable information disclosure via local access. (CVE-2022-0001)

  - Non-transparent sharing of branch predictor within a context in some Intel(R) Processors may allow an     authorized user to potentially enable information disclosure via local access. (CVE-2022-0002)

  - Racy interactions between dirty vram tracking and paging log dirty hypercalls Activation of log dirty mode     done by XEN_DMOP_track_dirty_vram (was named HVMOP_track_dirty_vram before Xen 4.9) is racy with ongoing     log dirty hypercalls. A suitably timed call to XEN_DMOP_track_dirty_vram can enable log dirty while     another CPU is still in the process of tearing down the structures related to a previously enabled log     dirty mode (XEN_DOMCTL_SHADOW_OP_OFF). This is due to lack of mutually exclusive locking between both     operations and can lead to entries being added in already freed slots, resulting in a memory leak.
    (CVE-2022-26356)

  - race in VT-d domain ID cleanup Xen domain IDs are up to 15 bits wide. VT-d hardware may allow for only     less than 15 bits to hold a domain ID associating a physical device with a particular domain. Therefore     internally Xen domain IDs are mapped to the smaller value range. The cleaning up of the housekeeping     structures has a race, allowing for VT-d domain IDs to be leaked and flushes to be bypassed.
    (CVE-2022-26357)

  - IOMMU: RMRR (VT-d) and unity map (AMD-Vi) handling issues T[his CNA information record relates to multiple     CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] Certain PCI devices in a     system might be assigned Reserved Memory Regions (specified via Reserved Memory Region Reporting, RMRR)     for Intel VT-d or Unity Mapping ranges for AMD-Vi. These are typically used for platform tasks such as     legacy USB emulation. Since the precise purpose of these regions is unknown, once a device associated with     such a region is active, the mappings of these regions need to remain continuouly accessible by the     device. This requirement has been violated. Subsequent DMA or interrupts from the device may have     unpredictable behaviour, ranging from IOMMU faults to memory corruption. (CVE-2022-26358, CVE-2022-26359,     CVE-2022-26360, CVE-2022-26361)

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

The remote SUSE Linux SLES12 / SLES_SAP12 host has packages installed that are affected by multiple vulnerabilities as referenced in the SUSE-SU-2022:1285-1 advisory.

  - LFENCE/JMP (mitigation V2-2) may not sufficiently mitigate CVE-2017-5715 on some AMD CPUs.
    (CVE-2021-26401)

  - Non-transparent sharing of branch predictor selectors between contexts in some Intel(R) Processors may     allow an authorized user to potentially enable information disclosure via local access. (CVE-2022-0001)

  - Non-transparent sharing of branch predictor within a context in some Intel(R) Processors may allow an     authorized user to potentially enable information disclosure via local access. (CVE-2022-0002)

  - Racy interactions between dirty vram tracking and paging log dirty hypercalls Activation of log dirty mode     done by XEN_DMOP_track_dirty_vram (was named HVMOP_track_dirty_vram before Xen 4.9) is racy with ongoing     log dirty hypercalls. A suitably timed call to XEN_DMOP_track_dirty_vram can enable log dirty while     another CPU is still in the process of tearing down the structures related to a previously enabled log     dirty mode (XEN_DOMCTL_SHADOW_OP_OFF). This is due to lack of mutually exclusive locking between both     operations and can lead to entries being added in already freed slots, resulting in a memory leak.
    (CVE-2022-26356)

  - race in VT-d domain ID cleanup Xen domain IDs are up to 15 bits wide. VT-d hardware may allow for only     less than 15 bits to hold a domain ID associating a physical device with a particular domain. Therefore     internally Xen domain IDs are mapped to the smaller value range. The cleaning up of the housekeeping     structures has a race, allowing for VT-d domain IDs to be leaked and flushes to be bypassed.
    (CVE-2022-26357)

  - IOMMU: RMRR (VT-d) and unity map (AMD-Vi) handling issues T[his CNA information record relates to multiple     CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] Certain PCI devices in a     system might be assigned Reserved Memory Regions (specified via Reserved Memory Region Reporting, RMRR)     for Intel VT-d or Unity Mapping ranges for AMD-Vi. These are typically used for platform tasks such as     legacy USB emulation. Since the precise purpose of these regions is unknown, once a device associated with     such a region is active, the mappings of these regions need to remain continuouly accessible by the     device. This requirement has been violated. Subsequent DMA or interrupts from the device may have     unpredictable behaviour, ranging from IOMMU faults to memory corruption. (CVE-2022-26358, CVE-2022-26359,     CVE-2022-26360, CVE-2022-26361)

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

ID	Name	Product	Family	Severity
435479	Alpine: multiple xen packages: security update to 4.15.2-r2	Tenable Cloud Security	Alpine Linux Local Security Checks	high
435479	Alpine: multiple xen packages: security update to 4.15.2-r2	Tenable Self-Hosted Container Security	Alpine Linux Local Security Checks	high
255332	Linux Distros Unpatched Vulnerability : CVE-2022-26360	Nessus	Misc.	high
424724	Alpine: multiple xen packages: security update to 4.16.1-r0	Tenable Cloud Security	Alpine Linux Local Security Checks	high
424724	Alpine: multiple xen packages: security update to 4.16.1-r0	Tenable Self-Hosted Container Security	Alpine Linux Local Security Checks	high
189976	GLSA-202402-07 : Xen: Multiple Vulnerabilities	Nessus	Gentoo Local Security Checks	high
407800	Alpine: xen: security update to 4.14.5-r0	Tenable Cloud Security	Alpine Linux Local Security Checks	high
407800	Alpine: xen: security update to 4.14.5-r0	Tenable Self-Hosted Container Security	Alpine Linux Local Security Checks	high
407788	Alpine: xen: security update to 4.13.4-r3	Tenable Cloud Security	Alpine Linux Local Security Checks	high
407788	Alpine: xen: security update to 4.13.4-r3	Tenable Self-Hosted Container Security	Alpine Linux Local Security Checks	high
162521	SUSE SLES15 Security Update : xen (SUSE-SU-2022:2158-1)	Nessus	SuSE Local Security Checks	high
162183	SUSE SLED15 / SLES15 Security Update : xen (SUSE-SU-2022:2065-1)	Nessus	SuSE Local Security Checks	high
160498	SUSE SLED15: xen / xen-devel / xen-doc-html / xen-libs / xen-libs-32bit / etc (SUSE-SU-2022:1506-1)	Nessus	SuSE Local Security Checks	high
160489	SUSE SLES12 Security Update : xen (SUSE-SU-2022:1505-1)	Nessus	SuSE Local Security Checks	high
160220	SUSE SLES12: xen / xen-doc-html / xen-libs / xen-libs-32bit / xen-tools / etc (SUSE-SU-2022:1408-1)	Nessus	SuSE Local Security Checks	high
160197	SUSE SLES15 Security Update : xen (SUSE-SU-2022:1359-1)	Nessus	SuSE Local Security Checks	high
160193	SUSE SLES12 Security Update : xen (SUSE-SU-2022:1375-1)	Nessus	SuSE Local Security Checks	high
160092	SUSE SLES15 Security Update : xen (SUSE-SU-2022:1300-1)	Nessus	SuSE Local Security Checks	high
160057	SUSE SLES12 Security Update : xen (SUSE-SU-2022:1285-1)	Nessus	SuSE Local Security Checks	high

Detections

Analytics

CVE-2022-26360

high

Tenable Plugins

high

high

high

high

high

high

high

high

high

high

high

high

high

high

high

high

high

high

high