Search Results (Refine Search)
- Results Type: Overview
- Keyword (text search): cpe:2.3:o:xen:xen:3.2.0:*:*:*:*:*:x86:*
- CPE Name Search: true
Vuln ID | Summary | CVSS Severity |
---|---|---|
CVE-2023-46837 |
Arm provides multiple helpers to clean & invalidate the cache for a given region. This is, for instance, used when allocating guest memory to ensure any writes (such as the ones during scrubbing) have reached memory before handing over the page to a guest. Unfortunately, the arithmetics in the helpers can overflow and would then result to skip the cache cleaning/invalidation. Therefore there is no guarantee when all the writes will reach the memory. This undefined behavior was meant to be addressed by XSA-437, but the approach was not sufficient. Published: January 05, 2024; 12:15:11 PM -0500 |
V4.0:(not available) V3.1: 3.3 LOW V2.0:(not available) |
CVE-2023-46836 |
The fixes for XSA-422 (Branch Type Confusion) and XSA-434 (Speculative Return Stack Overflow) are not IRQ-safe. It was believed that the mitigations always operated in contexts with IRQs disabled. However, the original XSA-254 fix for Meltdown (XPTI) deliberately left interrupts enabled on two entry paths; one unconditionally, and one conditionally on whether XPTI was active. As BTC/SRSO and Meltdown affect different CPU vendors, the mitigations are not active together by default. Therefore, there is a race condition whereby a malicious PV guest can bypass BTC/SRSO protections and launch a BTC/SRSO attack against Xen. Published: January 05, 2024; 12:15:11 PM -0500 |
V4.0:(not available) V3.1: 4.7 MEDIUM V2.0:(not available) |
CVE-2023-46835 |
The current setup of the quarantine page tables assumes that the quarantine domain (dom_io) has been initialized with an address width of DEFAULT_DOMAIN_ADDRESS_WIDTH (48) and hence 4 page table levels. However dom_io being a PV domain gets the AMD-Vi IOMMU page tables levels based on the maximum (hot pluggable) RAM address, and hence on systems with no RAM above the 512GB mark only 3 page-table levels are configured in the IOMMU. On systems without RAM above the 512GB boundary amd_iommu_quarantine_init() will setup page tables for the scratch page with 4 levels, while the IOMMU will be configured to use 3 levels only, resulting in the last page table directory (PDE) effectively becoming a page table entry (PTE), and hence a device in quarantine mode gaining write access to the page destined to be a PDE. Due to this page table level mismatch, the sink page the device gets read/write access to is no longer cleared between device assignment, possibly leading to data leaks. Published: January 05, 2024; 12:15:11 PM -0500 |
V4.0:(not available) V3.1: 5.5 MEDIUM V2.0:(not available) |
CVE-2023-34326 |
The caching invalidation guidelines from the AMD-Vi specification (48882—Rev 3.07-PUB—Oct 2022) is incorrect on some hardware, as devices will malfunction (see stale DMA mappings) if some fields of the DTE are updated but the IOMMU TLB is not flushed. Such stale DMA mappings can point to memory ranges not owned by the guest, thus allowing access to unindented memory regions. Published: January 05, 2024; 12:15:08 PM -0500 |
V4.0:(not available) V3.1: 7.8 HIGH V2.0:(not available) |
CVE-2023-34325 |
[This CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] libfsimage contains parsing code for several filesystems, most of them based on grub-legacy code. libfsimage is used by pygrub to inspect guest disks. Pygrub runs as the same user as the toolstack (root in a priviledged domain). At least one issue has been reported to the Xen Security Team that allows an attacker to trigger a stack buffer overflow in libfsimage. After further analisys the Xen Security Team is no longer confident in the suitability of libfsimage when run against guest controlled input with super user priviledges. In order to not affect current deployments that rely on pygrub patches are provided in the resolution section of the advisory that allow running pygrub in deprivileged mode. CVE-2023-4949 refers to the original issue in the upstream grub project ("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’s XFS file system implementation.") CVE-2023-34325 refers specifically to the vulnerabilities in Xen's copy of libfsimage, which is decended from a very old version of grub. Published: January 05, 2024; 12:15:08 PM -0500 |
V4.0:(not available) V3.1: 7.8 HIGH V2.0:(not available) |
CVE-2023-34323 |
When a transaction is committed, C Xenstored will first check the quota is correct before attempting to commit any nodes. It would be possible that accounting is temporarily negative if a node has been removed outside of the transaction. Unfortunately, some versions of C Xenstored are assuming that the quota cannot be negative and are using assert() to confirm it. This will lead to C Xenstored crash when tools are built without -DNDEBUG (this is the default). Published: January 05, 2024; 12:15:08 PM -0500 |
V4.0:(not available) V3.1: 5.5 MEDIUM V2.0:(not available) |
CVE-2023-34322 |
For migration as well as to work around kernels unaware of L1TF (see XSA-273), PV guests may be run in shadow paging mode. Since Xen itself needs to be mapped when PV guests run, Xen and shadowed PV guests run directly the respective shadow page tables. For 64-bit PV guests this means running on the shadow of the guest root page table. In the course of dealing with shortage of memory in the shadow pool associated with a domain, shadows of page tables may be torn down. This tearing down may include the shadow root page table that the CPU in question is presently running on. While a precaution exists to supposedly prevent the tearing down of the underlying live page table, the time window covered by that precaution isn't large enough. Published: January 05, 2024; 12:15:08 PM -0500 |
V4.0:(not available) V3.1: 7.8 HIGH V2.0:(not available) |
CVE-2023-34321 |
Arm provides multiple helpers to clean & invalidate the cache for a given region. This is, for instance, used when allocating guest memory to ensure any writes (such as the ones during scrubbing) have reached memory before handing over the page to a guest. Unfortunately, the arithmetics in the helpers can overflow and would then result to skip the cache cleaning/invalidation. Therefore there is no guarantee when all the writes will reach the memory. Published: January 05, 2024; 12:15:08 PM -0500 |
V4.0:(not available) V3.1: 3.3 LOW V2.0:(not available) |
CVE-2023-34320 |
Cortex-A77 cores (r0p0 and r1p0) are affected by erratum 1508412 where software, under certain circumstances, could deadlock a core due to the execution of either a load to device or non-cacheable memory, and either a store exclusive or register read of the Physical Address Register (PAR_EL1) in close proximity. Published: December 08, 2023; 4:15:07 PM -0500 |
V4.0:(not available) V3.1: 5.5 MEDIUM V2.0:(not available) |
CVE-2023-34319 |
The fix for XSA-423 added logic to Linux'es netback driver to deal with a frontend splitting a packet in a way such that not all of the headers would come in one piece. Unfortunately the logic introduced there didn't account for the extreme case of the entire packet being split into as many pieces as permitted by the protocol, yet still being smaller than the area that's specially dealt with to keep all (possible) headers together. Such an unusual packet would therefore trigger a buffer overrun in the driver. Published: September 22, 2023; 10:15:45 AM -0400 |
V4.0:(not available) V3.1: 7.8 HIGH V2.0:(not available) |
CVE-2022-42332 |
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. Published: March 21, 2023; 9:15:11 AM -0400 |
V4.0:(not available) V3.1: 7.8 HIGH V2.0:(not available) |
CVE-2022-42324 |
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. Published: November 01, 2022; 9:15:12 AM -0400 |
V4.0:(not available) V3.1: 5.5 MEDIUM V2.0:(not available) |
CVE-2022-33745 |
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. Published: July 26, 2022; 9:15:10 AM -0400 |
V4.0:(not available) V3.1: 8.8 HIGH V2.0:(not available) |
CVE-2022-21166 |
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. Published: June 15, 2022; 5:15:09 PM -0400 |
V4.0:(not available) V3.1: 5.5 MEDIUM V2.0: 2.1 LOW |
CVE-2022-21127 |
Incomplete cleanup in specific special register read operations for some Intel(R) Processors may allow an authenticated user to potentially enable information disclosure via local access. Published: June 15, 2022; 4:15:17 PM -0400 |
V4.0:(not available) V3.1: 5.5 MEDIUM V2.0: 2.1 LOW |
CVE-2022-21125 |
Incomplete cleanup of microarchitectural fill buffers on some Intel(R) Processors may allow an authenticated user to potentially enable information disclosure via local access. Published: June 15, 2022; 4:15:17 PM -0400 |
V4.0:(not available) V3.1: 5.5 MEDIUM V2.0: 2.1 LOW |
CVE-2022-21123 |
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. Published: June 15, 2022; 4:15:17 PM -0400 |
V4.0:(not available) V3.1: 5.5 MEDIUM V2.0: 2.1 LOW |
CVE-2022-26364 |
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. Published: June 09, 2022; 1:15:09 PM -0400 |
V4.0:(not available) V3.1: 6.7 MEDIUM V2.0: 7.2 HIGH |
CVE-2022-26363 |
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. Published: June 09, 2022; 1:15:08 PM -0400 |
V4.0:(not available) V3.1: 6.7 MEDIUM V2.0: 7.2 HIGH |
CVE-2022-26362 |
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. Published: June 09, 2022; 1:15:08 PM -0400 |
V4.0:(not available) V3.1: 6.4 MEDIUM V2.0: 6.9 MEDIUM |