Description
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)
Plugin Details
Supported Sensors: Agentless Assessment, Tenable Cloud Security, Tenable Self-Hosted Container Security
Risk Information
Vector: CVSS2#AV:L/AC:H/Au:N/C:C/I:C/A:C
Vector: CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Temporal Vector: CVSS:3.0/E:U/RL:O/RC:C
Vulnerability Information
Exploit Ease: No known exploits are available
Vulnerability Publication Date: 1/25/2022