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.

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

  - 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)

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:

  - PCI devices with RMRRs not deassigned correctly Certain PCI devices in a system might be assigned Reserved
    Memory Regions (specified via Reserved Memory Region Reporting, "RMRR"). These are typically used for
    platform tasks such as legacy USB emulation. If such a device is passed through to a guest, then on guest
    shutdown the device is not properly deassigned. The IOMMU configuration for these devices which are not
    properly deassigned ends up pointing to a freed data structure, including the IO Pagetables. Subsequent
    DMA or interrupts from the device will have unpredictable behaviour, ranging from IOMMU faults to memory
    corruption. (CVE-2021-28702)

  - 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)

  - certain VT-d IOMMUs may not work in shared page table mode For efficiency reasons, address translation
    control structures (page tables) may (and, on suitable hardware, by default will) be shared between CPUs,
    for second-level translation (EPT), and IOMMUs. These page tables are presently set up to always be 4
    levels deep. However, an IOMMU may require the use of just 3 page table levels. In such a configuration
    the lop level table needs to be stripped before inserting the root table's address into the hardware
    pagetable base register. When sharing page tables, Xen erroneously skipped this stripping. Consequently,
    the guest is able to write to leaf page table entries. (CVE-2021-28710)

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)

  - 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)

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 a vulnerability referenced in the following CVE:

  - 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)

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

    - CVE-2021-0089: Fixed Speculative Code Store Bypass (XSA-375) (bsc#1186433).
    - CVE-2021-20255: Fixed stack overflow via infinite recursion in eepro100 (bsc#1182654).
    - CVE-2021-28690: Fixed x86 TSX Async Abort protections not restored after S3 (XSA-377) (bsc#1186434).
    - CVE-2021-28692: Fixed inappropriate x86 IOMMU timeout detection / handling (XSA-373) (bsc#1186429).
    - CVE-2021-28697: Fixed grant table v2 status pages may remain accessible after de-allocation (XSA-379)     (bsc#1189376).
    - CVE-2021-28698: Fixed long running loops in grant table handling. (XSA-380) (bsc#1189378).
    - CVE-2021-28701: Fixed race condition in XENMAPSPACE_grant_table handling (XSA-384) (bsc#1189632).
    - CVE-2021-28703: Fixed grant table v2 status pages may remain accessible after de-allocation (take two)     (XSA-387) (bsc#1192555).
    - CVE-2021-28705, CVE-2021-28709: Fixed issues with partially successful P2M updates on x86 (XSA-389)     (bsc#1192559).
    - CVE-2021-28706: Fixed guests may exceed their designated memory limit (XSA-385) (bsc#1192554).
    - CVE-2021-3527: Fixed unbounded stack allocation in usbredir (bsc#1186013).
    - CVE-2021-3592: Fixed invalid pointer initialization may lead to information disclosure in slirp (bootp)     (bsc#1187369).
    - CVE-2021-3594: Fixed invalid pointer initialization may lead to information disclosure in slirp (udp)     (bsc#1187378).
    - CVE-2021-3595: Fixed invalid pointer initialization may lead to information disclosure in slirp (tftp)     (bsc#1187376).
    - CVE-2021-3682: Fixed free call on invalid pointer in usbredir bufp_alloc (bsc#1189150).
    - CVE-2021-3930: Fixed off-by-one error in mode_sense_page() in hw/scsi/scsi-disk.c (bsc#1192526).

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.

ID	Name	Product	Family	Severity
250439	Linux Distros Unpatched Vulnerability : CVE-2021-28703	Nessus	Misc.	high
424670	Alpine: multiple xen packages: security update to 4.15.1-r1	Tenable Cloud Security	Alpine Linux Local Security Checks	high
424670	Alpine: multiple xen packages: security update to 4.15.1-r1	Tenable Self-Hosted Container Security	Alpine Linux Local Security Checks	high
189976	GLSA-202402-07 : Xen: Multiple Vulnerabilities	Nessus	Gentoo Local Security Checks	high
407814	Alpine: xen: security update to 4.15.2-r0	Tenable Cloud Security	Alpine Linux Local Security Checks	high
407814	Alpine: xen: security update to 4.15.2-r0	Tenable Self-Hosted Container Security	Alpine Linux 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
407784	Alpine: xen: security update to 4.13.4-r0	Tenable Cloud Security	Alpine Linux Local Security Checks	high
407784	Alpine: xen: security update to 4.13.4-r0	Tenable Self-Hosted Container Security	Alpine Linux Local Security Checks	high
155812	SUSE SLES11: xen / xen-doc-html / xen-kmp-default / xen-kmp-pae / xen-libs / etc (SUSE-SU-2021:14848-1)	Nessus	SuSE Local Security Checks	high

Detections

Analytics

CVE-2021-28703

high

Tenable Plugins

high

high

high

high

high

high

high

high

high

high

high