{ "version": "1", "package": [ { "name": "xen-tools", "layer": "meta-xilinx-virtualization", "version": "4.21+stable-xilinx+git", "products": [ { "product": "xen-tools", "cvesInRecord": "No" } ], "issue": [ { "id": "CVE-2016-3960", "summary": "Integer overflow in the x86 shadow pagetable code in Xen allows local guest OS users to cause a denial of service (host crash) or possibly gain privileges by shadowing a superpage mapping.", "scorev2": "7.2", "scorev3": "8.8", "scorev4": "0.0", "vector": "LOCAL", "vectorString": "AV:L/AC:L/Au:N/C:C/I:C/A:C", "status": "Patched", "link": "https://nvd.nist.gov/vuln/detail/CVE-2016-3960", "detail": "fixed-version", "description": "XSA-173 shadow pagetables address-width overflow" }, { "id": "CVE-2016-7092", "summary": "The get_page_from_l3e function in arch/x86/mm.c in Xen allows local 32-bit PV guest OS administrators to gain host OS privileges via vectors related to L3 recursive pagetables.", "scorev2": "6.8", "scorev3": "8.2", "scorev4": "0.0", "vector": "LOCAL", "vectorString": "AV:L/AC:L/Au:S/C:C/I:C/A:C", "status": "Patched", "link": "https://nvd.nist.gov/vuln/detail/CVE-2016-7092", "detail": "fixed-version", "description": "XSA-185 32-bit L3 recursive PT" }, { "id": "CVE-2016-9379", "summary": "The pygrub boot loader emulator in Xen, when S-expression output format is requested, allows local pygrub-using guest OS administrators to read or delete arbitrary files on the host via string quotes and S-expressions in the bootloader configuration file.", "scorev2": "4.6", "scorev3": "7.9", "scorev4": "0.0", "vector": "LOCAL", "vectorString": "AV:L/AC:L/Au:N/C:P/I:P/A:P", "status": "Patched", "link": "https://nvd.nist.gov/vuln/detail/CVE-2016-9379", "detail": "fixed-version", "description": "XSA-198 pygrub S-expression delimiter injection" }, { "id": "CVE-2016-9380", "summary": "The pygrub boot loader emulator in Xen, when nul-delimited output format is requested, allows local pygrub-using guest OS administrators to read or delete arbitrary files on the host via NUL bytes in the bootloader configuration file.", "scorev2": "4.6", "scorev3": "7.5", "scorev4": "0.0", "vector": "LOCAL", "vectorString": "AV:L/AC:L/Au:N/C:P/I:P/A:P", "status": "Patched", "link": "https://nvd.nist.gov/vuln/detail/CVE-2016-9380", "detail": "fixed-version", "description": "XSA-198 pygrub" }, { "id": "CVE-2016-9383", "summary": "Xen, when running on a 64-bit hypervisor, allows local x86 guest OS users to modify arbitrary memory and consequently obtain sensitive information, cause a denial of service (host crash), or execute arbitrary code on the host by leveraging broken emulation of bit test instructions.", "scorev2": "7.2", "scorev3": "8.8", "scorev4": "0.0", "vector": "LOCAL", "vectorString": "AV:L/AC:L/Au:N/C:C/I:C/A:C", "status": "Patched", "link": "https://nvd.nist.gov/vuln/detail/CVE-2016-9383", "detail": "fixed-version", "description": "XSA-195 instruction-emulator BT" }, { "id": "CVE-2016-9386", "summary": "The x86 emulator in Xen does not properly treat x86 NULL segments as unusable when accessing memory, which might allow local HVM guest users to gain privileges via vectors involving \"unexpected\" base/limit values.", "scorev2": "4.6", "scorev3": "7.8", "scorev4": "0.0", "vector": "LOCAL", "vectorString": "AV:L/AC:L/Au:N/C:P/I:P/A:P", "status": "Patched", "link": "https://nvd.nist.gov/vuln/detail/CVE-2016-9386", "detail": "fixed-version", "description": "XSA-191 null segment usability" }, { "id": "CVE-2017-12135", "summary": "Xen allows local OS guest users to cause a denial of service (crash) or possibly obtain sensitive information or gain privileges via vectors involving transitive grants.", "scorev2": "4.6", "scorev3": "8.8", "scorev4": "0.0", "vector": "LOCAL", "vectorString": "AV:L/AC:L/Au:N/C:P/I:P/A:P", "status": "Patched", "link": "https://nvd.nist.gov/vuln/detail/CVE-2017-12135", "detail": "fixed-version", "description": "XSA-226 transitive grants" }, { "id": "CVE-2017-12137", "summary": "arch/x86/mm.c in Xen allows local PV guest OS users to gain host OS privileges via vectors related to map_grant_ref.", "scorev2": "7.2", "scorev3": "8.8", "scorev4": "0.0", "vector": "LOCAL", "vectorString": "AV:L/AC:L/Au:N/C:C/I:C/A:C", "status": "Patched", "link": "https://nvd.nist.gov/vuln/detail/CVE-2017-12137", "detail": "fixed-version", "description": "XSA-227 map_grant_ref refcount" }, { "id": "CVE-2017-7228", "summary": "An issue (known as XSA-212) was discovered in Xen, with fixes available for 4.8.x, 4.7.x, 4.6.x, 4.5.x, and 4.4.x. The earlier XSA-29 fix introduced an insufficient check on XENMEM_exchange input, allowing the caller to drive hypervisor memory accesses outside of the guest provided input/output arrays.", "scorev2": "7.2", "scorev3": "8.2", "scorev4": "0.0", "vector": "LOCAL", "vectorString": "AV:L/AC:L/Au:N/C:C/I:C/A:C", "status": "Patched", "link": "https://nvd.nist.gov/vuln/detail/CVE-2017-7228", "detail": "fixed-version", "description": "XSA-212 memory_exchange bound check" }, { "id": "CVE-2018-5244", "summary": "In Xen 4.10, new infrastructure was introduced as part of an overhaul to how MSR emulation happens for guests. Unfortunately, one tracking structure isn't freed when a vcpu is destroyed. This allows guest OS administrators to cause a denial of service (host OS memory consumption) by rebooting many times.", "scorev2": "4.9", "scorev3": "6.5", "scorev4": "0.0", "vector": "LOCAL", "vectorString": "AV:L/AC:L/Au:N/C:N/I:N/A:C", "status": "Patched", "link": "https://nvd.nist.gov/vuln/detail/CVE-2018-5244", "detail": "fixed-version", "description": "XSA-253 MSR emulation memory leak" }, { "id": "CVE-2018-8897", "summary": "A statement in the System Programming Guide of the Intel 64 and IA-32 Architectures Software Developer's Manual (SDM) was mishandled in the development of some or all operating-system kernels, resulting in unexpected behavior for #DB exceptions that are deferred by MOV SS or POP SS, as demonstrated by (for example) privilege escalation in Windows, macOS, some Xen configurations, or FreeBSD, or a Linux kernel crash. The MOV to SS and POP SS instructions inhibit interrupts (including NMIs), data breakpoints, and single step trap exceptions until the instruction boundary following the next instruction (SDM Vol. 3A; section 6.8.3). (The inhibited data breakpoints are those on memory accessed by the MOV to SS or POP to SS instruction itself.) Note that debug exceptions are not inhibited by the interrupt enable (EFLAGS.IF) system flag (SDM Vol. 3A; section 2.3). If the instruction following the MOV to SS or POP to SS instruction is an instruction like SYSCALL, SYSENTER, INT 3, etc. that transfers control to the operating system at CPL < 3, the debug exception is delivered after the transfer to CPL < 3 is complete. OS kernels may not expect this order of events and may therefore experience unexpected behavior when it occurs.", "scorev2": "7.2", "scorev3": "7.8", "scorev4": "0.0", "vector": "LOCAL", "vectorString": "AV:L/AC:L/Au:N/C:C/I:C/A:C", "status": "Patched", "link": "https://nvd.nist.gov/vuln/detail/CVE-2018-8897", "detail": "fixed-version", "description": "XSA-260 MOV/POP SS debug exception" }, { "id": "CVE-2021-26313", "summary": "Potential speculative code store bypass in all supported CPU products, in conjunction with software vulnerabilities relating to speculative execution of overwritten instructions, may cause an incorrect speculation and could result in data leakage.", "scorev2": "2.1", "scorev3": "5.5", "scorev4": "0.0", "vector": "LOCAL", "vectorString": "AV:L/AC:L/Au:N/C:P/I:N/A:N", "status": "Patched", "link": "https://nvd.nist.gov/vuln/detail/CVE-2021-26313", "detail": "fixed-version", "description": "XSA-375 Speculative Code Store Bypass" }, { "id": "CVE-2021-28692", "summary": "inappropriate x86 IOMMU timeout detection / handling IOMMUs process commands issued to them in parallel with the operation of the CPU(s) issuing such commands. In the current implementation in Xen, asynchronous notification of the completion of such commands is not used. Instead, the issuing CPU spin-waits for the completion of the most recently issued command(s). Some of these waiting loops try to apply a timeout to fail overly-slow commands. The course of action upon a perceived timeout actually being detected is inappropriate: - on Intel hardware guests which did not originally cause the timeout may be marked as crashed, - on AMD hardware higher layer callers would not be notified of the issue, making them continue as if the IOMMU operation succeeded.", "scorev2": "5.6", "scorev3": "7.1", "scorev4": "0.0", "vector": "LOCAL", "vectorString": "AV:L/AC:L/Au:N/C:P/I:N/A:C", "status": "Patched", "link": "https://nvd.nist.gov/vuln/detail/CVE-2021-28692", "detail": "fixed-version", "description": "XSA-373 IOMMU completion timeout" }, { "id": "CVE-2021-28694", "summary": "IOMMU page mapping issues on x86 T[his CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] Both AMD and Intel allow ACPI tables to specify regions of memory which should be left untranslated, which typically means these addresses should pass the translation phase unaltered. While these are typically device specific ACPI properties, they can also be specified to apply to a range of devices, or even all devices. On all systems with such regions Xen failed to prevent guests from undoing/replacing such mappings (CVE-2021-28694). On AMD systems, where a discontinuous range is specified by firmware, the supposedly-excluded middle range will also be identity-mapped (CVE-2021-28695). Further, on AMD systems, upon de-assigment of a physical device from a guest, the identity mappings would be left in place, allowing a guest continued access to ranges of memory which it shouldn't have access to anymore (CVE-2021-28696).", "scorev2": "4.6", "scorev3": "6.8", "scorev4": "0.0", "vector": "LOCAL", "vectorString": "AV:L/AC:L/Au:N/C:P/I:P/A:P", "status": "Patched", "link": "https://nvd.nist.gov/vuln/detail/CVE-2021-28694", "detail": "fixed-version", "description": "XSA-378 IOMMU page mapping" }, { "id": "CVE-2021-28695", "summary": "IOMMU page mapping issues on x86 T[his CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] Both AMD and Intel allow ACPI tables to specify regions of memory which should be left untranslated, which typically means these addresses should pass the translation phase unaltered. While these are typically device specific ACPI properties, they can also be specified to apply to a range of devices, or even all devices. On all systems with such regions Xen failed to prevent guests from undoing/replacing such mappings (CVE-2021-28694). On AMD systems, where a discontinuous range is specified by firmware, the supposedly-excluded middle range will also be identity-mapped (CVE-2021-28695). Further, on AMD systems, upon de-assigment of a physical device from a guest, the identity mappings would be left in place, allowing a guest continued access to ranges of memory which it shouldn't have access to anymore (CVE-2021-28696).", "scorev2": "4.6", "scorev3": "6.8", "scorev4": "0.0", "vector": "LOCAL", "vectorString": "AV:L/AC:L/Au:N/C:P/I:P/A:P", "status": "Patched", "link": "https://nvd.nist.gov/vuln/detail/CVE-2021-28695", "detail": "fixed-version", "description": "XSA-378 IOMMU page mapping" }, { "id": "CVE-2021-28696", "summary": "IOMMU page mapping issues on x86 T[his CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] Both AMD and Intel allow ACPI tables to specify regions of memory which should be left untranslated, which typically means these addresses should pass the translation phase unaltered. While these are typically device specific ACPI properties, they can also be specified to apply to a range of devices, or even all devices. On all systems with such regions Xen failed to prevent guests from undoing/replacing such mappings (CVE-2021-28694). On AMD systems, where a discontinuous range is specified by firmware, the supposedly-excluded middle range will also be identity-mapped (CVE-2021-28695). Further, on AMD systems, upon de-assigment of a physical device from a guest, the identity mappings would be left in place, allowing a guest continued access to ranges of memory which it shouldn't have access to anymore (CVE-2021-28696).", "scorev2": "4.6", "scorev3": "6.8", "scorev4": "0.0", "vector": "LOCAL", "vectorString": "AV:L/AC:L/Au:N/C:P/I:P/A:P", "status": "Patched", "link": "https://nvd.nist.gov/vuln/detail/CVE-2021-28696", "detail": "fixed-version", "description": "XSA-378 IOMMU page mapping" }, { "id": "CVE-2021-28698", "summary": "long running loops in grant table handling In order to properly monitor resource use, Xen maintains information on the grant mappings a domain may create to map grants offered by other domains. In the process of carrying out certain actions, Xen would iterate over all such entries, including ones which aren't in use anymore and some which may have been created but never used. If the number of entries for a given domain is large enough, this iterating of the entire table may tie up a CPU for too long, starving other domains or causing issues in the hypervisor itself. Note that a domain may map its own grants, i.e. there is no need for multiple domains to be involved here. A pair of \"cooperating\" guests may, however, cause the effects to be more severe.", "scorev2": "4.9", "scorev3": "5.5", "scorev4": "0.0", "vector": "LOCAL", "vectorString": "AV:L/AC:L/Au:N/C:N/I:N/A:C", "status": "Patched", "link": "https://nvd.nist.gov/vuln/detail/CVE-2021-28698", "detail": "fixed-version", "description": "XSA-380 long loops in grant table" }, { "id": "CVE-2021-28699", "summary": "inadequate grant-v2 status frames array bounds check The v2 grant table interface separates grant attributes from grant status. That is, when operating in this mode, a guest has two tables. As a result, guests also need to be able to retrieve the addresses that the new status tracking table can be accessed through. For 32-bit guests on x86, translation of requests has to occur because the interface structure layouts commonly differ between 32- and 64-bit. The translation of the request to obtain the frame numbers of the grant status table involves translating the resulting array of frame numbers. Since the space used to carry out the translation is limited, the translation layer tells the core function the capacity of the array within translation space. Unfortunately the core function then only enforces array bounds to be below 8 times the specified value, and would write past the available space if enough frame numbers needed storing.", "scorev2": "4.9", "scorev3": "5.5", "scorev4": "0.0", "vector": "LOCAL", "vectorString": "AV:L/AC:L/Au:N/C:N/I:N/A:C", "status": "Patched", "link": "https://nvd.nist.gov/vuln/detail/CVE-2021-28699", "detail": "fixed-version", "description": "XSA-382 grant-v2 status array bounds" }, { "id": "CVE-2021-28700", "summary": "xen/arm: No memory limit for dom0less domUs The dom0less feature allows an administrator to create multiple unprivileged domains directly from Xen. Unfortunately, the memory limit from them is not set. This allow a domain to allocate memory beyond what an administrator originally configured.", "scorev2": "6.8", "scorev3": "4.9", "scorev4": "0.0", "vector": "NETWORK", "vectorString": "AV:N/AC:L/Au:S/C:N/I:N/A:C", "status": "Patched", "link": "https://nvd.nist.gov/vuln/detail/CVE-2021-28700", "detail": "fixed-version", "description": "XSA-383 dom0less domU memory limit (Arm)" }, { "id": "CVE-2021-28701", "summary": "Another race in XENMAPSPACE_grant_table handling Guests are 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, are de-allocated when a guest switches (back) from v2 to v1. Freeing such pages requires that the hypervisor enforce that no parallel request can result in the addition of a mapping of such a page to a guest. That enforcement was missing, allowing guests to retain access to pages that were freed and perhaps re-used for other purposes. Unfortunately, when XSA-379 was being prepared, this similar issue was not noticed.", "scorev2": "4.4", "scorev3": "7.8", "scorev4": "0.0", "vector": "LOCAL", "vectorString": "AV:L/AC:M/Au:N/C:P/I:P/A:P", "status": "Patched", "link": "https://nvd.nist.gov/vuln/detail/CVE-2021-28701", "detail": "fixed-version", "description": "XSA-384 XENMAPSPACE_grant_table race" }, { "id": "CVE-2021-28703", "summary": "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.", "scorev2": "6.9", "scorev3": "7.0", "scorev4": "0.0", "vector": "LOCAL", "vectorString": "AV:L/AC:M/Au:N/C:C/I:C/A:C", "status": "Patched", "link": "https://nvd.nist.gov/vuln/detail/CVE-2021-28703", "detail": "fixed-version", "description": "XSA-387 grant v2 status pages take two (66f400c71d12)" }, { "id": "CVE-2022-21123", "summary": "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.", "scorev2": "2.1", "scorev3": "5.5", "scorev4": "0.0", "vector": "LOCAL", "vectorString": "AV:L/AC:L/Au:N/C:P/I:N/A:N", "status": "Patched", "link": "https://nvd.nist.gov/vuln/detail/CVE-2022-21123", "detail": "fixed-version", "description": "XSA-404 MMIO Stale Data; spec-ctrl=unpriv-mmio + FB_CLEAR present upstream" }, { "id": "CVE-2022-21125", "summary": "Incomplete cleanup of microarchitectural fill buffers on some Intel(R) Processors may allow an authenticated user to potentially enable information disclosure via local access.", "scorev2": "2.1", "scorev3": "5.5", "scorev4": "0.0", "vector": "LOCAL", "vectorString": "AV:L/AC:L/Au:N/C:P/I:N/A:N", "status": "Patched", "link": "https://nvd.nist.gov/vuln/detail/CVE-2022-21125", "detail": "fixed-version", "description": "XSA-404 MMIO Stale Data" }, { "id": "CVE-2022-21166", "summary": "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.", "scorev2": "2.1", "scorev3": "5.5", "scorev4": "0.0", "vector": "LOCAL", "vectorString": "AV:L/AC:L/Au:N/C:P/I:N/A:N", "status": "Patched", "link": "https://nvd.nist.gov/vuln/detail/CVE-2022-21166", "detail": "fixed-version", "description": "XSA-404 MMIO Stale Data" }, { "id": "CVE-2022-23033", "summary": "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.", "scorev2": "4.6", "scorev3": "7.8", "scorev4": "0.0", "vector": "LOCAL", "vectorString": "AV:L/AC:L/Au:N/C:P/I:P/A:P", "status": "Patched", "link": "https://nvd.nist.gov/vuln/detail/CVE-2022-23033", "detail": "fixed-version", "description": "XSA-393 guest_physmap_remove_page (Arm)" }, { "id": "CVE-2022-23035", "summary": "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.", "scorev2": "4.7", "scorev3": "4.6", "scorev4": "0.0", "vector": "LOCAL", "vectorString": "AV:L/AC:M/Au:N/C:N/I:N/A:C", "status": "Patched", "link": "https://nvd.nist.gov/vuln/detail/CVE-2022-23035", "detail": "fixed-version", "description": "XSA-395 passed-through device IRQ cleanup" }, { "id": "CVE-2022-23824", "summary": "IBPB may not prevent return branch predictions from being specified by pre-IBPB branch targets leading to a potential information disclosure.", "scorev2": "0.0", "scorev3": "5.5", "scorev4": "0.0", "vector": "LOCAL", "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N", "status": "Patched", "link": "https://nvd.nist.gov/vuln/detail/CVE-2022-23824", "detail": "fixed-version", "description": "XSA-422 multiple speculative + IBPB (AMD)" }, { "id": "CVE-2022-23960", "summary": "Certain Arm Cortex and Neoverse processors through 2022-03-08 do not properly restrict cache speculation, aka Spectre-BHB. An attacker can leverage the shared branch history in the Branch History Buffer (BHB) to influence mispredicted branches. Then, cache allocation can allow the attacker to obtain sensitive information.", "scorev2": "1.9", "scorev3": "5.6", "scorev4": "0.0", "vector": "LOCAL", "vectorString": "AV:L/AC:M/Au:N/C:P/I:N/A:N", "status": "Patched", "link": "https://nvd.nist.gov/vuln/detail/CVE-2022-23960", "detail": "fixed-version", "description": "XSA-398 Spectre-BHB (xen/arch/arm/cpuerrata.c)" }, { "id": "CVE-2022-26358", "summary": "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.", "scorev2": "4.4", "scorev3": "7.8", "scorev4": "0.0", "vector": "LOCAL", "vectorString": "AV:L/AC:M/Au:N/C:P/I:P/A:P", "status": "Patched", "link": "https://nvd.nist.gov/vuln/detail/CVE-2022-26358", "detail": "fixed-version", "description": "XSA-400 IOMMU RMRR / AMD unity map" }, { "id": "CVE-2022-26359", "summary": "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.", "scorev2": "4.4", "scorev3": "7.8", "scorev4": "0.0", "vector": "LOCAL", "vectorString": "AV:L/AC:M/Au:N/C:P/I:P/A:P", "status": "Patched", "link": "https://nvd.nist.gov/vuln/detail/CVE-2022-26359", "detail": "fixed-version", "description": "XSA-400 IOMMU RMRR / AMD unity map" }, { "id": "CVE-2022-26360", "summary": "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.", "scorev2": "4.4", "scorev3": "7.8", "scorev4": "0.0", "vector": "LOCAL", "vectorString": "AV:L/AC:M/Au:N/C:P/I:P/A:P", "status": "Patched", "link": "https://nvd.nist.gov/vuln/detail/CVE-2022-26360", "detail": "fixed-version", "description": "XSA-400 IOMMU RMRR / AMD unity map" }, { "id": "CVE-2022-26361", "summary": "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.", "scorev2": "4.4", "scorev3": "7.8", "scorev4": "0.0", "vector": "LOCAL", "vectorString": "AV:L/AC:M/Au:N/C:P/I:P/A:P", "status": "Patched", "link": "https://nvd.nist.gov/vuln/detail/CVE-2022-26361", "detail": "fixed-version", "description": "XSA-400 IOMMU RMRR / AMD unity map" }, { "id": "CVE-2022-26362", "summary": "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.", "scorev2": "6.9", "scorev3": "6.4", "scorev4": "0.0", "vector": "LOCAL", "vectorString": "AV:L/AC:M/Au:N/C:C/I:C/A:C", "status": "Patched", "link": "https://nvd.nist.gov/vuln/detail/CVE-2022-26362", "detail": "fixed-version", "description": "XSA-401 typeref acquisition race" }, { "id": "CVE-2022-26363", "summary": "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.", "scorev2": "7.2", "scorev3": "6.7", "scorev4": "0.0", "vector": "LOCAL", "vectorString": "AV:L/AC:L/Au:N/C:C/I:C/A:C", "status": "Patched", "link": "https://nvd.nist.gov/vuln/detail/CVE-2022-26363", "detail": "fixed-version", "description": "XSA-402 non-coherent mappings" }, { "id": "CVE-2022-26364", "summary": "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.", "scorev2": "7.2", "scorev3": "6.7", "scorev4": "0.0", "vector": "LOCAL", "vectorString": "AV:L/AC:L/Au:N/C:C/I:C/A:C", "status": "Patched", "link": "https://nvd.nist.gov/vuln/detail/CVE-2022-26364", "detail": "fixed-version", "description": "XSA-402 non-coherent mappings" }, { "id": "CVE-2022-29900", "summary": "Mis-trained branch predictions for return instructions may allow arbitrary speculative code execution under certain microarchitecture-dependent conditions.", "scorev2": "2.1", "scorev3": "6.5", "scorev4": "0.0", "vector": "LOCAL", "vectorString": "AV:L/AC:L/Au:N/C:P/I:N/A:N", "status": "Patched", "link": "https://nvd.nist.gov/vuln/detail/CVE-2022-29900", "detail": "fixed-version", "description": "XSA-407 Retbleed (AMD)" }, { "id": "CVE-2022-33745", "summary": "insufficient TLB flush for x86 PV guests in shadow mode For migration as well as to work around kernels unaware of L1TF (see XSA-273), PV guests may be run in shadow paging mode. To address XSA-401, code was moved inside a function in Xen. This code movement missed a variable changing meaning / value between old and new code positions. The now wrong use of the variable did lead to a wrong TLB flush condition, omitting flushes where such are necessary.", "scorev2": "0.0", "scorev3": "8.8", "scorev4": "0.0", "vector": "LOCAL", "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H", "status": "Patched", "link": "https://nvd.nist.gov/vuln/detail/CVE-2022-33745", "detail": "fixed-version", "description": "XSA-408 shadow-mode TLB flush" }, { "id": "CVE-2022-33747", "summary": "Arm: unbounded memory consumption for 2nd-level page tables Certain actions require e.g. removing pages from a guest's P2M (Physical-to-Machine) mapping. When large pages are in use to map guest pages in the 2nd-stage page tables, such a removal operation may incur a memory allocation (to replace a large mapping with individual smaller ones). These memory allocations are taken from the global memory pool. A malicious guest might be able to cause the global memory pool to be exhausted by manipulating its own P2M mappings.", "scorev2": "0.0", "scorev3": "3.8", "scorev4": "0.0", "vector": "LOCAL", "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:N/I:N/A:L", "status": "Patched", "link": "https://nvd.nist.gov/vuln/detail/CVE-2022-33747", "detail": "fixed-version", "description": "XSA-409 2nd-level pagetable bound (Arm)" }, { "id": "CVE-2022-33748", "summary": "lock order inversion in transitive grant copy handling As part of XSA-226 a missing cleanup call was inserted on an error handling path. While doing so, locking requirements were not paid attention to. As a result two cooperating guests granting each other transitive grants can cause locks to be acquired nested within one another, but in respectively opposite order. With suitable timing between the involved grant copy operations this may result in the locking up of a CPU.", "scorev2": "0.0", "scorev3": "5.6", "scorev4": "0.0", "vector": "LOCAL", "vectorString": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:C/C:N/I:N/A:H", "status": "Patched", "link": "https://nvd.nist.gov/vuln/detail/CVE-2022-33748", "detail": "fixed-version", "description": "XSA-411 transitive grant copy lock order" }, { "id": "CVE-2022-40982", "summary": "Information exposure through microarchitectural state after transient execution in certain vector execution units for some Intel(R) Processors may allow an authenticated user to potentially enable information disclosure via local access.", "scorev2": "0.0", "scorev3": "6.5", "scorev4": "0.0", "vector": "LOCAL", "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N", "status": "Patched", "link": "https://nvd.nist.gov/vuln/detail/CVE-2022-40982", "detail": "fixed-version", "description": "XSA-435 Gather Data Sampling (Intel)" }, { "id": "CVE-2022-42309", "summary": "Xenstore: Guests can crash xenstored Due to a bug in the fix of XSA-115 a malicious guest can cause xenstored to use a wrong pointer during node creation in an error path, resulting in a crash of xenstored or a memory corruption in xenstored causing further damage. Entering the error path can be controlled by the guest e.g. by exceeding the quota value of maximum nodes per domain.", "scorev2": "0.0", "scorev3": "8.8", "scorev4": "0.0", "vector": "LOCAL", "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H", "status": "Patched", "link": "https://nvd.nist.gov/vuln/detail/CVE-2022-42309", "detail": "fixed-version", "description": "XSA-414 tools/xenstored" }, { "id": "CVE-2022-42311", "summary": "Xenstore: guests can let run xenstored out of memory T[his CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] Malicious guests can cause xenstored to allocate vast amounts of memory, eventually resulting in a Denial of Service (DoS) of xenstored. There are multiple ways how guests can cause large memory allocations in xenstored: - - by issuing new requests to xenstored without reading the responses, causing the responses to be buffered in memory - - by causing large number of watch events to be generated via setting up multiple xenstore watches and then e.g. deleting many xenstore nodes below the watched path - - by creating as many nodes as allowed with the maximum allowed size and path length in as many transactions as possible - - by accessing many nodes inside a transaction", "scorev2": "0.0", "scorev3": "6.5", "scorev4": "0.0", "vector": "LOCAL", "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:N/I:N/A:H", "status": "Patched", "link": "https://nvd.nist.gov/vuln/detail/CVE-2022-42311", "detail": "fixed-version", "description": "XSA-326 tools/xenstored" }, { "id": "CVE-2022-42312", "summary": "Xenstore: guests can let run xenstored out of memory T[his CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] Malicious guests can cause xenstored to allocate vast amounts of memory, eventually resulting in a Denial of Service (DoS) of xenstored. There are multiple ways how guests can cause large memory allocations in xenstored: - - by issuing new requests to xenstored without reading the responses, causing the responses to be buffered in memory - - by causing large number of watch events to be generated via setting up multiple xenstore watches and then e.g. deleting many xenstore nodes below the watched path - - by creating as many nodes as allowed with the maximum allowed size and path length in as many transactions as possible - - by accessing many nodes inside a transaction", "scorev2": "0.0", "scorev3": "6.5", "scorev4": "0.0", "vector": "LOCAL", "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:N/I:N/A:H", "status": "Patched", "link": "https://nvd.nist.gov/vuln/detail/CVE-2022-42312", "detail": "fixed-version", "description": "XSA-326 tools/xenstored" }, { "id": "CVE-2022-42313", "summary": "Xenstore: guests can let run xenstored out of memory T[his CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] Malicious guests can cause xenstored to allocate vast amounts of memory, eventually resulting in a Denial of Service (DoS) of xenstored. There are multiple ways how guests can cause large memory allocations in xenstored: - - by issuing new requests to xenstored without reading the responses, causing the responses to be buffered in memory - - by causing large number of watch events to be generated via setting up multiple xenstore watches and then e.g. deleting many xenstore nodes below the watched path - - by creating as many nodes as allowed with the maximum allowed size and path length in as many transactions as possible - - by accessing many nodes inside a transaction", "scorev2": "0.0", "scorev3": "6.5", "scorev4": "0.0", "vector": "LOCAL", "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:N/I:N/A:H", "status": "Patched", "link": "https://nvd.nist.gov/vuln/detail/CVE-2022-42313", "detail": "fixed-version", "description": "XSA-326 tools/xenstored" }, { "id": "CVE-2022-42314", "summary": "Xenstore: guests can let run xenstored out of memory T[his CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] Malicious guests can cause xenstored to allocate vast amounts of memory, eventually resulting in a Denial of Service (DoS) of xenstored. There are multiple ways how guests can cause large memory allocations in xenstored: - - by issuing new requests to xenstored without reading the responses, causing the responses to be buffered in memory - - by causing large number of watch events to be generated via setting up multiple xenstore watches and then e.g. deleting many xenstore nodes below the watched path - - by creating as many nodes as allowed with the maximum allowed size and path length in as many transactions as possible - - by accessing many nodes inside a transaction", "scorev2": "0.0", "scorev3": "6.5", "scorev4": "0.0", "vector": "LOCAL", "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:N/I:N/A:H", "status": "Patched", "link": "https://nvd.nist.gov/vuln/detail/CVE-2022-42314", "detail": "fixed-version", "description": "XSA-326 tools/xenstored" }, { "id": "CVE-2022-42315", "summary": "Xenstore: guests can let run xenstored out of memory T[his CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] Malicious guests can cause xenstored to allocate vast amounts of memory, eventually resulting in a Denial of Service (DoS) of xenstored. There are multiple ways how guests can cause large memory allocations in xenstored: - - by issuing new requests to xenstored without reading the responses, causing the responses to be buffered in memory - - by causing large number of watch events to be generated via setting up multiple xenstore watches and then e.g. deleting many xenstore nodes below the watched path - - by creating as many nodes as allowed with the maximum allowed size and path length in as many transactions as possible - - by accessing many nodes inside a transaction", "scorev2": "0.0", "scorev3": "6.5", "scorev4": "0.0", "vector": "LOCAL", "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:N/I:N/A:H", "status": "Patched", "link": "https://nvd.nist.gov/vuln/detail/CVE-2022-42315", "detail": "fixed-version", "description": "XSA-326 tools/xenstored" }, { "id": "CVE-2022-42316", "summary": "Xenstore: guests can let run xenstored out of memory T[his CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] Malicious guests can cause xenstored to allocate vast amounts of memory, eventually resulting in a Denial of Service (DoS) of xenstored. There are multiple ways how guests can cause large memory allocations in xenstored: - - by issuing new requests to xenstored without reading the responses, causing the responses to be buffered in memory - - by causing large number of watch events to be generated via setting up multiple xenstore watches and then e.g. deleting many xenstore nodes below the watched path - - by creating as many nodes as allowed with the maximum allowed size and path length in as many transactions as possible - - by accessing many nodes inside a transaction", "scorev2": "0.0", "scorev3": "6.5", "scorev4": "0.0", "vector": "LOCAL", "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:N/I:N/A:H", "status": "Patched", "link": "https://nvd.nist.gov/vuln/detail/CVE-2022-42316", "detail": "fixed-version", "description": "XSA-326 tools/xenstored" }, { "id": "CVE-2022-42317", "summary": "Xenstore: guests can let run xenstored out of memory T[his CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] Malicious guests can cause xenstored to allocate vast amounts of memory, eventually resulting in a Denial of Service (DoS) of xenstored. There are multiple ways how guests can cause large memory allocations in xenstored: - - by issuing new requests to xenstored without reading the responses, causing the responses to be buffered in memory - - by causing large number of watch events to be generated via setting up multiple xenstore watches and then e.g. deleting many xenstore nodes below the watched path - - by creating as many nodes as allowed with the maximum allowed size and path length in as many transactions as possible - - by accessing many nodes inside a transaction", "scorev2": "0.0", "scorev3": "6.5", "scorev4": "0.0", "vector": "LOCAL", "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:N/I:N/A:H", "status": "Patched", "link": "https://nvd.nist.gov/vuln/detail/CVE-2022-42317", "detail": "fixed-version", "description": "XSA-326 tools/xenstored" }, { "id": "CVE-2022-42318", "summary": "Xenstore: guests can let run xenstored out of memory T[his CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] Malicious guests can cause xenstored to allocate vast amounts of memory, eventually resulting in a Denial of Service (DoS) of xenstored. There are multiple ways how guests can cause large memory allocations in xenstored: - - by issuing new requests to xenstored without reading the responses, causing the responses to be buffered in memory - - by causing large number of watch events to be generated via setting up multiple xenstore watches and then e.g. deleting many xenstore nodes below the watched path - - by creating as many nodes as allowed with the maximum allowed size and path length in as many transactions as possible - - by accessing many nodes inside a transaction", "scorev2": "0.0", "scorev3": "6.5", "scorev4": "0.0", "vector": "LOCAL", "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:N/I:N/A:H", "status": "Patched", "link": "https://nvd.nist.gov/vuln/detail/CVE-2022-42318", "detail": "fixed-version", "description": "XSA-326 tools/xenstored" }, { "id": "CVE-2022-42319", "summary": "Xenstore: Guests can cause Xenstore to not free temporary memory When working on a request of a guest, xenstored might need to allocate quite large amounts of memory temporarily. This memory is freed only after the request has been finished completely. A request is regarded to be finished only after the guest has read the response message of the request from the ring page. Thus a guest not reading the response can cause xenstored to not free the temporary memory. This can result in memory shortages causing Denial of Service (DoS) of xenstored.", "scorev2": "0.0", "scorev3": "6.5", "scorev4": "0.0", "vector": "LOCAL", "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:N/I:N/A:H", "status": "Patched", "link": "https://nvd.nist.gov/vuln/detail/CVE-2022-42319", "detail": "fixed-version", "description": "XSA-416 tools/xenstored" }, { "id": "CVE-2022-42320", "summary": "Xenstore: Guests can get access to Xenstore nodes of deleted domains Access rights of Xenstore nodes are per domid. When a domain is gone, there might be Xenstore nodes left with access rights containing the domid of the removed domain. This is normally no problem, as those access right entries will be corrected when such a node is written later. There is a small time window when a new domain is created, where the access rights of a past domain with the same domid as the new one will be regarded to be still valid, leading to the new domain being able to get access to a node which was meant to be accessible by the removed domain. For this to happen another domain needs to write the node before the newly created domain is being introduced to Xenstore by dom0.", "scorev2": "0.0", "scorev3": "7.0", "scorev4": "0.0", "vector": "LOCAL", "vectorString": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H", "status": "Patched", "link": "https://nvd.nist.gov/vuln/detail/CVE-2022-42320", "detail": "fixed-version", "description": "XSA-417 tools/xenstored" }, { "id": "CVE-2022-42321", "summary": "Xenstore: Guests can crash xenstored via exhausting the stack Xenstored is using recursion for some Xenstore operations (e.g. for deleting a sub-tree of Xenstore nodes). With sufficiently deep nesting levels this can result in stack exhaustion on xenstored, leading to a crash of xenstored.", "scorev2": "0.0", "scorev3": "6.5", "scorev4": "0.0", "vector": "LOCAL", "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:N/I:N/A:H", "status": "Patched", "link": "https://nvd.nist.gov/vuln/detail/CVE-2022-42321", "detail": "fixed-version", "description": "XSA-418 tools/xenstored" }, { "id": "CVE-2022-42322", "summary": "Xenstore: Cooperating guests can create arbitrary numbers of nodes T[his CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] Since the fix of XSA-322 any Xenstore node owned by a removed domain will be modified to be owned by Dom0. This will allow two malicious guests working together to create an arbitrary number of Xenstore nodes. This is possible by domain A letting domain B write into domain A's local Xenstore tree. Domain B can then create many nodes and reboot. The nodes created by domain B will now be owned by Dom0. By repeating this process over and over again an arbitrary number of nodes can be created, as Dom0's number of nodes isn't limited by Xenstore quota.", "scorev2": "0.0", "scorev3": "5.5", "scorev4": "0.0", "vector": "LOCAL", "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H", "status": "Patched", "link": "https://nvd.nist.gov/vuln/detail/CVE-2022-42322", "detail": "fixed-version", "description": "XSA-419 tools/xenstored" }, { "id": "CVE-2022-42323", "summary": "Xenstore: Cooperating guests can create arbitrary numbers of nodes T[his CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] Since the fix of XSA-322 any Xenstore node owned by a removed domain will be modified to be owned by Dom0. This will allow two malicious guests working together to create an arbitrary number of Xenstore nodes. This is possible by domain A letting domain B write into domain A's local Xenstore tree. Domain B can then create many nodes and reboot. The nodes created by domain B will now be owned by Dom0. By repeating this process over and over again an arbitrary number of nodes can be created, as Dom0's number of nodes isn't limited by Xenstore quota.", "scorev2": "0.0", "scorev3": "5.5", "scorev4": "0.0", "vector": "LOCAL", "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H", "status": "Patched", "link": "https://nvd.nist.gov/vuln/detail/CVE-2022-42323", "detail": "fixed-version", "description": "XSA-419 tools/xenstored" }, { "id": "CVE-2022-42324", "summary": "Oxenstored 32->31 bit integer truncation issues Integers in Ocaml are 63 or 31 bits of signed precision. The Ocaml Xenbus library takes a C uint32_t out of the ring and casts it directly to an Ocaml integer. In 64-bit Ocaml builds this is fine, but in 32-bit builds, it truncates off the most significant bit, and then creates unsigned/signed confusion in the remainder. This in turn can feed a negative value into logic not expecting a negative value, resulting in unexpected exceptions being thrown. The unexpected exception is not handled suitably, creating a busy-loop trying (and failing) to take the bad packet out of the xenstore ring.", "scorev2": "0.0", "scorev3": "5.5", "scorev4": "0.0", "vector": "LOCAL", "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H", "status": "Patched", "link": "https://nvd.nist.gov/vuln/detail/CVE-2022-42324", "detail": "fixed-version", "description": "XSA-420 tools/ocaml/xenstored 32->31 bit truncation" }, { "id": "CVE-2022-42325", "summary": "Xenstore: Guests can create arbitrary number of nodes via transactions T[his CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] In case a node has been created in a transaction and it is later deleted in the same transaction, the transaction will be terminated with an error. As this error is encountered only when handling the deleted node at transaction finalization, the transaction will have been performed partially and without updating the accounting information. This will enable a malicious guest to create arbitrary number of nodes.", "scorev2": "0.0", "scorev3": "5.5", "scorev4": "0.0", "vector": "LOCAL", "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H", "status": "Patched", "link": "https://nvd.nist.gov/vuln/detail/CVE-2022-42325", "detail": "fixed-version", "description": "XSA-421 tools/xenstored" }, { "id": "CVE-2022-42326", "summary": "Xenstore: Guests can create arbitrary number of nodes via transactions T[his CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] In case a node has been created in a transaction and it is later deleted in the same transaction, the transaction will be terminated with an error. As this error is encountered only when handling the deleted node at transaction finalization, the transaction will have been performed partially and without updating the accounting information. This will enable a malicious guest to create arbitrary number of nodes.", "scorev2": "0.0", "scorev3": "5.5", "scorev4": "0.0", "vector": "LOCAL", "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H", "status": "Patched", "link": "https://nvd.nist.gov/vuln/detail/CVE-2022-42326", "detail": "fixed-version", "description": "XSA-421 tools/xenstored" }, { "id": "CVE-2022-42332", "summary": "x86 shadow plus log-dirty mode use-after-free In environments where host assisted address translation is necessary but Hardware Assisted Paging (HAP) is unavailable, Xen will run guests in so called shadow mode. Shadow mode maintains a pool of memory used for both shadow page tables as well as auxiliary data structures. To migrate or snapshot guests, Xen additionally runs them in so called log-dirty mode. The data structures needed by the log-dirty tracking are part of aformentioned auxiliary data. In order to keep error handling efforts within reasonable bounds, for operations which may require memory allocations shadow mode logic ensures up front that enough memory is available for the worst case requirements. Unfortunately, while page table memory is properly accounted for on the code path requiring the potential establishing of new shadows, demands by the log-dirty infrastructure were not taken into consideration. As a result, just established shadow page tables could be freed again immediately, while other code is still accessing them on the assumption that they would remain allocated.", "scorev2": "0.0", "scorev3": "7.8", "scorev4": "0.0", "vector": "LOCAL", "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H", "status": "Patched", "link": "https://nvd.nist.gov/vuln/detail/CVE-2022-42332", "detail": "fixed-version", "description": "XSA-427 shadow + log-dirty UAF" }, { "id": "CVE-2022-4949", "summary": "The AdSanity plugin for WordPress is vulnerable to arbitrary file uploads due to missing file type validation in the 'ajax_upload' function in versions up to, and including, 1.8.1. This makes it possible for authenticated attackers with Contributor+ level privileges to upload arbitrary files on the affected sites server which makes remote code execution possible.", "scorev2": "0.0", "scorev3": "8.8", "scorev4": "0.0", "vector": "NETWORK", "vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H", "status": "Patched", "link": "https://nvd.nist.gov/vuln/detail/CVE-2022-4949", "detail": "fixed-version", "description": "XSA-443 tools/libs/fsimage + pygrub deprivileged mode" }, { "id": "CVE-2023-20588", "summary": "\nA division-by-zero error on some AMD processors can potentially return speculative data resulting in loss of confidentiality.\u00a0\n\n\n\n\n\n\n\n", "scorev2": "0.0", "scorev3": "5.5", "scorev4": "0.0", "vector": "LOCAL", "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N", "status": "Patched", "link": "https://nvd.nist.gov/vuln/detail/CVE-2023-20588", "detail": "fixed-version", "description": "XSA-439 divide speculative leak (AMD)" }, { "id": "CVE-2023-34320", "summary": "Cortex-A77 cores (r0p0 and r1p0) are affected by erratum 1508412\nwhere software, under certain circumstances, could deadlock a core\ndue to the execution of either a load to device or non-cacheable memory,\nand either a store exclusive or register read of the Physical\nAddress Register (PAR_EL1) in close proximity.\n", "scorev2": "0.0", "scorev3": "5.5", "scorev4": "0.0", "vector": "LOCAL", "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H", "status": "Patched", "link": "https://nvd.nist.gov/vuln/detail/CVE-2023-34320", "detail": "fixed-version", "description": "XSA-436 Cortex-A77 deadlock (Arm)" }, { "id": "CVE-2023-34325", "summary": "\n[This CNA information record relates to multiple CVEs; the\ntext explains which aspects/vulnerabilities correspond to which CVE.]\n\nlibfsimage contains parsing code for several filesystems, most of them based on\ngrub-legacy code. libfsimage is used by pygrub to inspect guest disks.\n\nPygrub runs as the same user as the toolstack (root in a priviledged domain).\n\nAt least one issue has been reported to the Xen Security Team that allows an\nattacker to trigger a stack buffer overflow in libfsimage. After further\nanalisys the Xen Security Team is no longer confident in the suitability of\nlibfsimage when run against guest controlled input with super user priviledges.\n\nIn order to not affect current deployments that rely on pygrub patches are\nprovided in the resolution section of the advisory that allow running pygrub in\ndeprivileged mode.\n\nCVE-2023-4949 refers to the original issue in the upstream grub\nproject (\"An attacker with local access to a system (either through a\ndisk or external drive) can present a modified XFS partition to\ngrub-legacy in such a way to exploit a memory corruption in grub\u2019s XFS\nfile system implementation.\") CVE-2023-34325 refers specifically to\nthe vulnerabilities in Xen's copy of libfsimage, which is decended\nfrom a very old version of grub.\n", "scorev2": "0.0", "scorev3": "7.8", "scorev4": "0.0", "vector": "LOCAL", "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H", "status": "Patched", "link": "https://nvd.nist.gov/vuln/detail/CVE-2023-34325", "detail": "fixed-version", "description": "XSA-443 tools/libs/fsimage + pygrub deprivileged mode" }, { "id": "CVE-2023-34326", "summary": "The caching invalidation guidelines from the AMD-Vi specification (48882\u2014Rev\n3.07-PUB\u2014Oct 2022) is incorrect on some hardware, as devices will malfunction\n(see stale DMA mappings) if some fields of the DTE are updated but the IOMMU\nTLB is not flushed.\n\nSuch stale DMA mappings can point to memory ranges not owned by the guest, thus\nallowing access to unindented memory regions.\n", "scorev2": "0.0", "scorev3": "7.8", "scorev4": "0.0", "vector": "LOCAL", "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H", "status": "Patched", "link": "https://nvd.nist.gov/vuln/detail/CVE-2023-34326", "detail": "fixed-version", "description": "XSA-442 IOMMU TLB flushing (AMD)" }, { "id": "CVE-2023-34327", "summary": "\n[This CNA information record relates to multiple CVEs; the\ntext explains which aspects/vulnerabilities correspond to which CVE.]\n\nAMD CPUs since ~2014 have extensions to normal x86 debugging functionality.\nXen supports guests using these extensions.\n\nUnfortunately there are errors in Xen's handling of the guest state, leading\nto denials of service.\n\n 1) CVE-2023-34327 - An HVM vCPU can end up operating in the context of\n a previous vCPUs debug mask state.\n\n 2) CVE-2023-34328 - A PV vCPU can place a breakpoint over the live GDT.\n This allows the PV vCPU to exploit XSA-156 / CVE-2015-8104 and lock\n up the CPU entirely.\n", "scorev2": "0.0", "scorev3": "5.5", "scorev4": "0.0", "vector": "LOCAL", "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H", "status": "Patched", "link": "https://nvd.nist.gov/vuln/detail/CVE-2023-34327", "detail": "fixed-version", "description": "XSA-444 Debug Mask handling (AMD)" }, { "id": "CVE-2023-46835", "summary": "The current setup of the quarantine page tables assumes that the\nquarantine domain (dom_io) has been initialized with an address width\nof DEFAULT_DOMAIN_ADDRESS_WIDTH (48) and hence 4 page table levels.\n\nHowever dom_io being a PV domain gets the AMD-Vi IOMMU page tables\nlevels based on the maximum (hot pluggable) RAM address, and hence on\nsystems with no RAM above the 512GB mark only 3 page-table levels are\nconfigured in the IOMMU.\n\nOn systems without RAM above the 512GB boundary\namd_iommu_quarantine_init() will setup page tables for the scratch\npage with 4 levels, while the IOMMU will be configured to use 3 levels\nonly, resulting in the last page table directory (PDE) effectively\nbecoming a page table entry (PTE), and hence a device in quarantine\nmode gaining write access to the page destined to be a PDE.\n\nDue to this page table level mismatch, the sink page the device gets\nread/write access to is no longer cleared between device assignment,\npossibly leading to data leaks.\n", "scorev2": "0.0", "scorev3": "5.5", "scorev4": "0.0", "vector": "LOCAL", "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N", "status": "Patched", "link": "https://nvd.nist.gov/vuln/detail/CVE-2023-46835", "detail": "fixed-version", "description": "XSA-445 IOMMU quarantine PT levels (AMD)" }, { "id": "CVE-2023-46836", "summary": "The fixes for XSA-422 (Branch Type Confusion) and XSA-434 (Speculative\nReturn Stack Overflow) are not IRQ-safe. It was believed that the\nmitigations always operated in contexts with IRQs disabled.\n\nHowever, the original XSA-254 fix for Meltdown (XPTI) deliberately left\ninterrupts enabled on two entry paths; one unconditionally, and one\nconditionally on whether XPTI was active.\n\nAs BTC/SRSO and Meltdown affect different CPU vendors, the mitigations\nare not active together by default. Therefore, there is a race\ncondition whereby a malicious PV guest can bypass BTC/SRSO protections\nand launch a BTC/SRSO attack against Xen.\n", "scorev2": "0.0", "scorev3": "4.7", "scorev4": "0.0", "vector": "LOCAL", "vectorString": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:N", "status": "Patched", "link": "https://nvd.nist.gov/vuln/detail/CVE-2023-46836", "detail": "fixed-version", "description": "XSA-446 BTC/SRSO completeness (AMD)" }, { "id": "CVE-2023-46841", "summary": "Recent x86 CPUs offer functionality named Control-flow Enforcement\nTechnology (CET). A sub-feature of this are Shadow Stacks (CET-SS).\nCET-SS is a hardware feature designed to protect against Return Oriented\nProgramming attacks. When enabled, traditional stacks holding both data\nand return addresses are accompanied by so called \"shadow stacks\",\nholding little more than return addresses. Shadow stacks aren't\nwritable by normal instructions, and upon function returns their\ncontents are used to check for possible manipulation of a return address\ncoming from the traditional stack.\n\nIn particular certain memory accesses need intercepting by Xen. In\nvarious cases the necessary emulation involves kind of replaying of\nthe instruction. Such replaying typically involves filling and then\ninvoking of a stub. Such a replayed instruction may raise an\nexceptions, which is expected and dealt with accordingly.\n\nUnfortunately the interaction of both of the above wasn't right:\nRecovery involves removal of a call frame from the (traditional) stack.\nThe counterpart of this operation for the shadow stack was missing.", "scorev2": "0.0", "scorev3": "6.5", "scorev4": "0.0", "vector": "LOCAL", "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:N/I:N/A:H", "status": "Patched", "link": "https://nvd.nist.gov/vuln/detail/CVE-2023-46841", "detail": "fixed-version", "description": "XSA-451 shadow stack vs emulation-stub exceptions" }, { "id": "CVE-2023-4949", "summary": "An attacker with local access to a system (either through a disk or external drive) can present a modified XFS partition to grub-legacy in such a way to exploit a memory corruption in grub\u2019s XFS file system implementation.\n", "scorev2": "0.0", "scorev3": "8.1", "scorev4": "0.0", "vector": "LOCAL", "vectorString": "CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:C/C:H/I:L/A:H", "status": "Patched", "link": "https://nvd.nist.gov/vuln/detail/CVE-2023-4949", "detail": "fixed-version", "description": "XSA-443 upstream GRUB issue mirrored in libfsimage; covered by deprivileged-pygrub work upstream" } ] } ] }