CPE Details
Alerte pour un CPE
Stay informed of any changes for a specific CPE.
CPE Name: cpe:2.3:o:xen:xen:4.12.0:*:*:*:*:x86:*:*
Informations
Vendor
xenProduct
xenVersion
4.12.0Target Software
x86Related CVE
| CVE ID | Published | Description | Score | Severity |
|---|---|---|---|---|
16h34 +00:00 |
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. | 4.7 |
Medium |
|
16h34 +00:00 |
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. | 5.5 |
Medium |
|
16h34 +00:00 |
[This CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] AMD CPUs since ~2014 have extensions to normal x86 debugging functionality. Xen supports guests using these extensions. Unfortunately there are errors in Xen's handling of the guest state, leading to denials of service. 1) CVE-2023-34327 - An HVM vCPU can end up operating in the context of a previous vCPUs debug mask state. 2) CVE-2023-34328 - A PV vCPU can place a breakpoint over the live GDT. This allows the PV vCPU to exploit XSA-156 / CVE-2015-8104 and lock up the CPU entirely. | 5.5 |
Medium |
|
16h34 +00:00 |
[This CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] AMD CPUs since ~2014 have extensions to normal x86 debugging functionality. Xen supports guests using these extensions. Unfortunately there are errors in Xen's handling of the guest state, leading to denials of service. 1) CVE-2023-34327 - An HVM vCPU can end up operating in the context of a previous vCPUs debug mask state. 2) CVE-2023-34328 - A PV vCPU can place a breakpoint over the live GDT. This allows the PV vCPU to exploit XSA-156 / CVE-2015-8104 and lock up the CPU entirely. | 5.5 |
Medium |
|
16h31 +00:00 |
[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. | 7.8 |
High |
|
16h30 +00:00 |
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. | 7.8 |
High |
|
16h30 +00:00 |
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). | 5.5 |
Medium |
|
20h54 +00:00 |
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. | 5.5 |
Medium |
|
23h00 +00:00 |
Xenstore: Guests can create orphaned Xenstore nodes By creating multiple nodes inside a transaction resulting in an error, a malicious guest can create orphaned nodes in the Xenstore data base, as the cleanup after the error will not remove all nodes already created. When the transaction is committed after this situation, nodes without a valid parent can be made permanent in the data base. | 5.5 |
Medium |
|
23h00 +00:00 |
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. | 6.5 |
Medium |
|
23h00 +00:00 |
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. | 5.5 |
Medium |
|
23h00 +00:00 |
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. | 5.5 |
Medium |
|
23h00 +00:00 |
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. | 5.5 |
Medium |
|
22h00 +00:00 |
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. | 5.6 |
Medium |
|
11h02 +00:00 |
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. | 7.8 |
High |
|
16h46 +00:00 |
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). | 6.8 |
Medium |
|
16h46 +00:00 |
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). | 6.8 |
Medium |
|
16h46 +00:00 |
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). | 6.8 |
Medium |
|
16h37 +00:00 |
grant table v2 status pages may remain accessible after de-allocation 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. | 7.8 |
High |
|
16h32 +00:00 |
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. | 5.5 |
Medium |
|
16h21 +00:00 |
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. | 5.5 |
Medium |
|
08h32 +00:00 |
xen/arm: Boot modules are not scrubbed The bootloader will load boot modules (e.g. kernel, initramfs...) in a temporary area before they are copied by Xen to each domain memory. To ensure sensitive data is not leaked from the modules, Xen must "scrub" them before handing the page over to the allocator. Unfortunately, it was discovered that modules will not be scrubbed on Arm. | 5.5 |
Medium |
|
08h27 +00:00 |
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. | 7.1 |
High |
|
09h16 +00:00 |
x86: TSX Async Abort protections not restored after S3 This issue relates to the TSX Async Abort speculative security vulnerability. Please see https://xenbits.xen.org/xsa/advisory-305.html for details. Mitigating TAA by disabling TSX (the default and preferred option) requires selecting a non-default setting in MSR_TSX_CTRL. This setting isn't restored after S3 suspend. | 6.5 |
Medium |
|
12h54 +00:00 |
HVM soft-reset crashes toolstack libxl requires all data structures passed across its public interface to be initialized before use and disposed of afterwards by calling a specific set of functions. Many internal data structures also require this initialize / dispose discipline, but not all of them. When the "soft reset" feature was implemented, the libxl__domain_suspend_state structure didn't require any initialization or disposal. At some point later, an initialization function was introduced for the structure; but the "soft reset" path wasn't refactored to call the initialization function. When a guest nwo initiates a "soft reboot", uninitialized data structure leads to an assert() when later code finds the structure in an unexpected state. The effect of this is to crash the process monitoring the guest. How this affects the system depends on the structure of the toolstack. For xl, this will have no security-relevant effect: every VM has its own independent monitoring process, which contains no state. The domain in question will hang in a crashed state, but can be destroyed by `xl destroy` just like any other non-cooperating domain. For daemon-based toolstacks linked against libxl, such as libvirt, this will crash the toolstack, losing the state of any in-progress operations (localized DoS), and preventing further administrator operations unless the daemon is configured to restart automatically (system-wide DoS). If crashes "leak" resources, then repeated crashes could use up resources, also causing a system-wide DoS. | 5.5 |
Medium |
|
11h23 +00:00 |
Potential floating point value injection in all supported CPU products, in conjunction with software vulnerabilities relating to speculative execution with incorrect floating point results, may cause the use of incorrect data from FPVI and may result in data leakage. | 5.5 |
Medium |
|
11h23 +00:00 |
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. | 5.5 |
Medium |
|
17h00 +00:00 |
An issue was discovered in Xen through 4.14.x. Nodes in xenstore have an ownership. In oxenstored, a owner could give a node away. However, node ownership has quota implications. Any guest can run another guest out of quota, or create an unbounded number of nodes owned by dom0, thus running xenstored out of memory A malicious guest administrator can cause a denial of service against a specific guest or against the whole host. All systems using oxenstored are vulnerable. Building and using oxenstored is the default in the upstream Xen distribution, if the Ocaml compiler is available. Systems using C xenstored are not vulnerable. | 6 |
Medium |
|
16h51 +00:00 |
An issue was discovered in Xen through 4.14.x. Access rights of Xenstore nodes are per domid. Unfortunately, existing granted access rights are not removed when a domain is being destroyed. This means that a new domain created with the same domid will inherit the access rights to Xenstore nodes from the previous domain(s) with the same domid. Because all Xenstore entries of a guest below /local/domain/ |
8.8 |
High |
|
16h26 +00:00 |
An issue was discovered in Xen 4.6 through 4.14.x. When acting upon a guest XS_RESET_WATCHES request, not all tracking information is freed. A guest can cause unbounded memory usage in oxenstored. This can lead to a system-wide DoS. Only systems using the Ocaml Xenstored implementation are vulnerable. Systems using the C Xenstored implementation are not vulnerable. | 5.5 |
Medium |
|
16h25 +00:00 |
An issue was discovered in Xen through 4.14.x. When a Xenstore watch fires, the xenstore client that registered the watch will receive a Xenstore message containing the path of the modified Xenstore entry that triggered the watch, and the tag that was specified when registering the watch. Any communication with xenstored is done via Xenstore messages, consisting of a message header and the payload. The payload length is limited to 4096 bytes. Any request to xenstored resulting in a response with a payload longer than 4096 bytes will result in an error. When registering a watch, the payload length limit applies to the combined length of the watched path and the specified tag. Because watches for a specific path are also triggered for all nodes below that path, the payload of a watch event message can be longer than the payload needed to register the watch. A malicious guest that registers a watch using a very large tag (i.e., with a registration operation payload length close to the 4096 byte limit) can cause the generation of watch events with a payload length larger than 4096 bytes, by writing to Xenstore entries below the watched path. This will result in an error condition in xenstored. This error can result in a NULL pointer dereference, leading to a crash of xenstored. A malicious guest administrator can cause xenstored to crash, leading to a denial of service. Following a xenstored crash, domains may continue to run, but management operations will be impossible. Only C xenstored is affected, oxenstored is not affected. | 6 |
Medium |
|
16h15 +00:00 |
An issue was discovered in Xen through 4.14.x. Xenstored and guests communicate via a shared memory page using a specific protocol. When a guest violates this protocol, xenstored will drop the connection to that guest. Unfortunately, this is done by just removing the guest from xenstored's internal management, resulting in the same actions as if the guest had been destroyed, including sending an @releaseDomain event. @releaseDomain events do not say that the guest has been removed. All watchers of this event must look at the states of all guests to find the guest that has been removed. When an @releaseDomain is generated due to a domain xenstored protocol violation, because the guest is still running, the watchers will not react. Later, when the guest is actually destroyed, xenstored will no longer have it stored in its internal data base, so no further @releaseDomain event will be sent. This can lead to a zombie domain; memory mappings of that guest's memory will not be removed, due to the missing event. This zombie domain will be cleaned up only after another domain is destroyed, as that will trigger another @releaseDomain event. If the device model of the guest that violated the Xenstore protocol is running in a stub-domain, a use-after-free case could happen in xenstored, after having removed the guest from its internal data base, possibly resulting in a crash of xenstored. A malicious guest can block resources of the host for a period after its own death. Guests with a stub domain device model can eventually crash xenstored, resulting in a more serious denial of service (the prevention of any further domain management operations). Only the C variant of Xenstore is affected; the Ocaml variant is not affected. Only HVM guests with a stubdom device model can cause a serious DoS. | 6.5 |
Medium |
|
16h14 +00:00 |
An issue was discovered in Xen through 4.14.x. A guest may access xenstore paths via absolute paths containing a full pathname, or via a relative path, which implicitly includes /local/domain/$DOMID for their own domain id. Management tools must access paths in guests' namespaces, necessarily using absolute paths. oxenstored imposes a pathname limit that is applied solely to the relative or absolute path specified by the client. Therefore, a guest can create paths in its own namespace which are too long for management tools to access. Depending on the toolstack in use, a malicious guest administrator might cause some management tools and debugging operations to fail. For example, a guest administrator can cause "xenstore-ls -r" to fail. However, a guest administrator cannot prevent the host administrator from tearing down the domain. All systems using oxenstored are vulnerable. Building and using oxenstored is the default in the upstream Xen distribution, if the Ocaml compiler is available. Systems using C xenstored are not vulnerable. | 6 |
Medium |
|
16h08 +00:00 |
An issue was discovered in Xen through 4.14.x. Neither xenstore implementation does any permission checks when reporting a xenstore watch event. A guest administrator can watch the root xenstored node, which will cause notifications for every created, modified, and deleted key. A guest administrator can also use the special watches, which will cause a notification every time a domain is created and destroyed. Data may include: number, type, and domids of other VMs; existence and domids of driver domains; numbers of virtual interfaces, block devices, vcpus; existence of virtual framebuffers and their backend style (e.g., existence of VNC service); Xen VM UUIDs for other domains; timing information about domain creation and device setup; and some hints at the backend provisioning of VMs and their devices. The watch events do not contain values stored in xenstore, only key names. A guest administrator can observe non-sensitive domain and device lifecycle events relating to other guests. This information allows some insight into overall system configuration (including the number and general nature of other guests), and configuration of other guests (including the number and general nature of other guests' devices). This information might be commercially interesting or might make other attacks easier. There is not believed to be exposure of sensitive data. Specifically, there is no exposure of VNC passwords, port numbers, pathnames in host and guest filesystems, cryptographic keys, or within-guest data. | 2.3 |
Low |
|
16h06 +00:00 |
An issue was discovered in Xen through 4.14.x. In the Ocaml xenstored implementation, the internal representation of the tree has special cases for the root node, because this node has no parent. Unfortunately, permissions were not checked for certain operations on the root node. Unprivileged guests can get and modify permissions, list, and delete the root node. (Deleting the whole xenstore tree is a host-wide denial of service.) Achieving xenstore write access is also possible. All systems using oxenstored are vulnerable. Building and using oxenstored is the default in the upstream Xen distribution, if the Ocaml compiler is available. Systems using C xenstored are not vulnerable. | 8.8 |
High |
|
16h01 +00:00 |
An issue was discovered in Xen through 4.14.x. Recording of the per-vCPU control block mapping maintained by Xen and that of pointers into the control block is reversed. The consumer assumes, seeing the former initialized, that the latter are also ready for use. Malicious or buggy guest kernels can mount a Denial of Service (DoS) attack affecting the entire system. | 6.2 |
Medium |
|
16h00 +00:00 |
An issue was discovered in the Linux kernel through 5.10.1, as used with Xen through 4.14.x. The Linux kernel PV block backend expects the kernel thread handler to reset ring->xenblkd to NULL when stopped. However, the handler may not have time to run if the frontend quickly toggles between the states connect and disconnect. As a consequence, the block backend may re-use a pointer after it was freed. A misbehaving guest can trigger a dom0 crash by continuously connecting / disconnecting a block frontend. Privilege escalation and information leaks cannot be ruled out. This only affects systems with a Linux blkback. | 8.8 |
High |
|
15h52 +00:00 |
An issue was discovered in Xen through 4.14.x. Some OSes (such as Linux, FreeBSD, and NetBSD) are processing watch events using a single thread. If the events are received faster than the thread is able to handle, they will get queued. As the queue is unbounded, a guest may be able to trigger an OOM in the backend. All systems with a FreeBSD, Linux, or NetBSD (any version) dom0 are vulnerable. | 6.5 |
Medium |
|
15h07 +00:00 |
An issue was discovered in Xen through 4.14.x allowing x86 HVM guest OS users to cause a denial of service (stack corruption), cause a data leak, or possibly gain privileges because of an off-by-one error. NOTE: this issue is caused by an incorrect fix for CVE-2020-27671. | 8.8 |
High |
|
17h17 +00:00 |
Xen through 4.14.x allows guest OS administrators to obtain sensitive information (such as AES keys from outside the guest) via a side-channel attack on a power/energy monitoring interface, aka a "Platypus" attack. NOTE: there is only one logically independent fix: to change the access control for each such interface in Xen. | 4.4 |
Medium |
|
18h34 +00:00 |
An issue was discovered in Xen through 4.14.x allowing x86 HVM and PVH guest OS users to cause a denial of service (data corruption), cause a data leak, or possibly gain privileges because coalescing of per-page IOMMU TLB flushes is mishandled. | 7.8 |
High |
|
18h33 +00:00 |
An issue was discovered in the Linux kernel through 5.9.1, as used with Xen through 4.14.x. Guest OS users can cause a denial of service (host OS hang) via a high rate of events to dom0, aka CID-e99502f76271. | 5.5 |
Medium |
|
19h34 +00:00 |
An issue was discovered in Xen through 4.14.x. There are missing memory barriers when accessing/allocating an event channel. Event channels control structures can be accessed lockless as long as the port is considered to be valid. Such a sequence is missing an appropriate memory barrier (e.g., smp_*mb()) to prevent both the compiler and CPU from re-ordering access. A malicious guest may be able to cause a hypervisor crash resulting in a Denial of Service (DoS). Information leak and privilege escalation cannot be excluded. Systems running all versions of Xen are affected. Whether a system is vulnerable will depend on the CPU and compiler used to build Xen. For all systems, the presence and the scope of the vulnerability depend on the precise re-ordering performed by the compiler used to build Xen. We have not been able to survey compilers; consequently we cannot say which compiler(s) might produce vulnerable code (with which code generation options). GCC documentation clearly suggests that re-ordering is possible. Arm systems will also be vulnerable if the CPU is able to re-order memory access. Please consult your CPU vendor. x86 systems are only vulnerable if a compiler performs re-ordering. | 7.8 |
High |
|
19h28 +00:00 |
An issue was discovered in Xen through 4.14.x. x86 PV guest kernels can experience denial of service via SYSENTER. The SYSENTER instruction leaves various state sanitization activities to software. One of Xen's sanitization paths injects a #GP fault, and incorrectly delivers it twice to the guest. This causes the guest kernel to observe a kernel-privilege #GP fault (typically fatal) rather than a user-privilege #GP fault (usually converted into SIGSEGV/etc.). Malicious or buggy userspace can crash the guest kernel, resulting in a VM Denial of Service. All versions of Xen from 3.2 onwards are vulnerable. Only x86 systems are vulnerable. ARM platforms are not vulnerable. Only x86 systems that support the SYSENTER instruction in 64bit mode are vulnerable. This is believed to be Intel, Centaur, and Shanghai CPUs. AMD and Hygon CPUs are not believed to be vulnerable. Only x86 PV guests can exploit the vulnerability. x86 PVH / HVM guests cannot exploit the vulnerability. | 5.5 |
Medium |
|
19h18 +00:00 |
An issue was discovered in Xen through 4.14.x. There is a race condition when migrating timers between x86 HVM vCPUs. When migrating timers of x86 HVM guests between its vCPUs, the locking model used allows for a second vCPU of the same guest (also operating on the timers) to release a lock that it didn't acquire. The most likely effect of the issue is a hang or crash of the hypervisor, i.e., a Denial of Service (DoS). All versions of Xen are affected. Only x86 systems are vulnerable. Arm systems are not vulnerable. Only x86 HVM guests can leverage the vulnerability. x86 PV and PVH cannot leverage the vulnerability. Only guests with more than one vCPU can exploit the vulnerability. | 4.7 |
Medium |
|
19h16 +00:00 |
An issue was discovered in Xen through 4.14.x. An x86 PV guest can trigger a host OS crash when handling guest access to MSR_MISC_ENABLE. When a guest accesses certain Model Specific Registers, Xen first reads the value from hardware to use as the basis for auditing the guest access. For the MISC_ENABLE MSR, which is an Intel specific MSR, this MSR read is performed without error handling for a #GP fault, which is the consequence of trying to read this MSR on non-Intel hardware. A buggy or malicious PV guest administrator can crash Xen, resulting in a host Denial of Service. Only x86 systems are vulnerable. ARM systems are not vulnerable. Only Xen versions 4.11 and onwards are vulnerable. 4.10 and earlier are not vulnerable. Only x86 systems that do not implement the MISC_ENABLE MSR (0x1a0) are vulnerable. AMD and Hygon systems do not implement this MSR and are vulnerable. Intel systems do implement this MSR and are not vulnerable. Other manufacturers have not been checked. Only x86 PV guests can exploit the vulnerability. x86 HVM/PVH guests cannot exploit the vulnerability. | 6 |
Medium |
|
19h14 +00:00 |
An issue was discovered in Xen through 4.14.x. There is a lack of preemption in evtchn_reset() / evtchn_destroy(). In particular, the FIFO event channel model allows guests to have a large number of event channels active at a time. Closing all of these (when resetting all event channels or when cleaning up after the guest) may take extended periods of time. So far, there was no arrangement for preemption at suitable intervals, allowing a CPU to spend an almost unbounded amount of time in the processing of these operations. Malicious or buggy guest kernels can mount a Denial of Service (DoS) attack affecting the entire system. All Xen versions are vulnerable in principle. Whether versions 4.3 and older are vulnerable depends on underlying hardware characteristics. | 5.5 |
Medium |
|
19h10 +00:00 |
An issue was discovered in Xen through 4.14.x. There are evtchn_reset() race conditions. Uses of EVTCHNOP_reset (potentially by a guest on itself) or XEN_DOMCTL_soft_reset (by itself covered by XSA-77) can lead to the violation of various internal assumptions. This may lead to out of bounds memory accesses or triggering of bug checks. In particular, x86 PV guests may be able to elevate their privilege to that of the host. Host and guest crashes are also possible, leading to a Denial of Service (DoS). Information leaks cannot be ruled out. All Xen versions from 4.5 onwards are vulnerable. Xen versions 4.4 and earlier are not vulnerable. | 7 |
High |
|
19h07 +00:00 |
An issue was discovered in Xen 4.14.x. There is a missing unlock in the XENMEM_acquire_resource error path. The RCU (Read, Copy, Update) mechanism is a synchronisation primitive. A buggy error path in the XENMEM_acquire_resource exits without releasing an RCU reference, which is conceptually similar to forgetting to unlock a spinlock. A buggy or malicious HVM stubdomain can cause an RCU reference to be leaked. This causes subsequent administration operations, (e.g., CPU offline) to livelock, resulting in a host Denial of Service. The buggy codepath has been present since Xen 4.12. Xen 4.14 and later are vulnerable to the DoS. The side effects are believed to be benign on Xen 4.12 and 4.13, but patches are provided nevertheless. The vulnerability can generally only be exploited by x86 HVM VMs, as these are generally the only type of VM that have a Qemu stubdomain. x86 PV and PVH domains, as well as ARM VMs, typically don't use a stubdomain. Only VMs using HVM stubdomains can exploit the vulnerability. VMs using PV stubdomains, or with emulators running in dom0, cannot exploit the vulnerability. | 5.5 |
Medium |
|
19h05 +00:00 |
An issue was discovered in Xen through 4.14.x. There is mishandling of the constraint that once-valid event channels may not turn invalid. Logic in the handling of event channel operations in Xen assumes that an event channel, once valid, will not become invalid over the life time of a guest. However, operations like the resetting of all event channels may involve decreasing one of the bounds checked when determining validity. This may lead to bug checks triggering, crashing the host. An unprivileged guest may be able to crash Xen, leading to a Denial of Service (DoS) for the entire system. All Xen versions from 4.4 onwards are vulnerable. Xen versions 4.3 and earlier are not vulnerable. Only systems with untrusted guests permitted to create more than the default number of event channels are vulnerable. This number depends on the architecture and type of guest. For 32-bit x86 PV guests, this is 1023; for 64-bit x86 PV guests, and for all ARM guests, this number is 4095. Systems where untrusted guests are limited to fewer than this number are not vulnerable. Note that xl and libxl limit max_event_channels to 1023 by default, so systems using exclusively xl, libvirt+libxl, or their own toolstack based on libxl, and not explicitly setting max_event_channels, are not vulnerable. | 6.5 |
Medium |
|
19h01 +00:00 |
An issue was discovered in Xen through 4.14.x. The PCI passthrough code improperly uses register data. Code paths in Xen's MSI handling have been identified that act on unsanitized values read back from device hardware registers. While devices strictly compliant with PCI specifications shouldn't be able to affect these registers, experience shows that it's very common for devices to have out-of-spec "backdoor" operations that can affect the result of these reads. A not fully trusted guest may be able to crash Xen, leading to a Denial of Service (DoS) for the entire system. Privilege escalation and information leaks cannot be excluded. All versions of Xen supporting PCI passthrough are affected. Only x86 systems are vulnerable. Arm systems are not vulnerable. Only guests with passed through PCI devices may be able to leverage the vulnerability. Only systems passing through devices with out-of-spec ("backdoor") functionality can cause issues. Experience shows that such out-of-spec functionality is common; unless you have reason to believe that your device does not have such functionality, it's better to assume that it does. | 7.8 |
High |
|
10h26 +00:00 |
An issue was discovered in Xen through 4.13.x, allowing Intel guest OS users to gain privileges or cause a denial of service because of non-atomic modification of a live EPT PTE. When mapping guest EPT (nested paging) tables, Xen would in some circumstances use a series of non-atomic bitfield writes. Depending on the compiler version and optimisation flags, Xen might expose a dangerous partially written PTE to the hardware, which an attacker might be able to race to exploit. A guest administrator or perhaps even an unprivileged guest user might be able to cause denial of service, data corruption, or privilege escalation. Only systems using Intel CPUs are vulnerable. Systems using AMD CPUs, and Arm systems, are not vulnerable. Only systems using nested paging (hap, aka nested paging, aka in this case Intel EPT) are vulnerable. Only HVM and PVH guests can exploit the vulnerability. The presence and scope of the vulnerability depends on the precise optimisations performed by the compiler used to build Xen. If the compiler generates (a) a single 64-bit write, or (b) a series of read-modify-write operations in the same order as the source code, the hypervisor is not vulnerable. For example, in one test build using GCC 8.3 with normal settings, the compiler generated multiple (unlocked) read-modify-write operations in source-code order, which did not constitute a vulnerability. We have not been able to survey compilers; consequently we cannot say which compiler(s) might produce vulnerable code (with which code-generation options). The source code clearly violates the C rules, and thus should be considered vulnerable. | 7.8 |
High |
|
10h23 +00:00 |
An issue was discovered in Xen through 4.13.x, allowing guest OS users to cause a host OS crash because of incorrect error handling in event-channel port allocation. The allocation of an event-channel port may fail for multiple reasons: (1) port is already in use, (2) the memory allocation failed, or (3) the port we try to allocate is higher than what is supported by the ABI (e.g., 2L or FIFO) used by the guest or the limit set by an administrator (max_event_channels in xl cfg). Due to the missing error checks, only (1) will be considered an error. All the other cases will provide a valid port and will result in a crash when trying to access the event channel. When the administrator configured a guest to allow more than 1023 event channels, that guest may be able to crash the host. When Xen is out-of-memory, allocation of new event channels will result in crashing the host rather than reporting an error. Xen versions 4.10 and later are affected. All architectures are affected. The default configuration, when guests are created with xl/libxl, is not vulnerable, because of the default event-channel limit. | 6.5 |
Medium |
|
10h20 +00:00 |
An issue was discovered in Xen through 4.13.x, allowing guest OS users to cause a denial of service because of a bad error path in GNTTABOP_map_grant. Grant table operations are expected to return 0 for success, and a negative number for errors. Some misplaced brackets cause one error path to return 1 instead of a negative value. The grant table code in Linux treats this condition as success, and proceeds with incorrectly initialised state. A buggy or malicious guest can construct its grant table in such a way that, when a backend domain tries to map a grant, it hits the incorrect error path. This will crash a Linux based dom0 or backend domain. | 5.5 |
Medium |
|
10h19 +00:00 |
An issue was discovered in Xen through 4.13.x, allowing guest OS users to cause a denial of service because of bad continuation handling in GNTTABOP_copy. Grant table operations are expected to return 0 for success, and a negative number for errors. The fix for CVE-2017-12135 introduced a path through grant copy handling where success may be returned to the caller without any action taken. In particular, the status fields of individual operations are left uninitialised, and may result in errant behaviour in the caller of GNTTABOP_copy. A buggy or malicious guest can construct its grant table in such a way that, when a backend domain tries to copy a grant, it hits the incorrect exit path. This returns success to the caller without doing anything, which may cause crashes or other incorrect behaviour. | 5.5 |
Medium |
|
10h18 +00:00 |
An issue was discovered in xenoprof in Xen through 4.13.x, allowing guest OS users (with active profiling) to obtain sensitive information about other guests, cause a denial of service, or possibly gain privileges. For guests for which "active" profiling was enabled by the administrator, the xenoprof code uses the standard Xen shared ring structure. Unfortunately, this code did not treat the guest as a potential adversary: it trusts the guest not to modify buffer size information or modify head / tail pointers in unexpected ways. This can crash the host (DoS). Privilege escalation cannot be ruled out. | 8.8 |
High |
|
10h18 +00:00 |
An issue was discovered in xenoprof in Xen through 4.13.x, allowing guest OS users (without active profiling) to obtain sensitive information about other guests. Unprivileged guests can request to map xenoprof buffers, even if profiling has not been enabled for those guests. These buffers were not scrubbed. | 5.5 |
Medium |
|
10h17 +00:00 |
An issue was discovered in Xen through 4.13.x, allowing guest OS users to cause a denial of service or possibly gain privileges because of missing memory barriers in read-write unlock paths. The read-write unlock paths don't contain a memory barrier. On Arm, this means a processor is allowed to re-order the memory access with the preceding ones. In other words, the unlock may be seen by another processor before all the memory accesses within the "critical" section. As a consequence, it may be possible to have a writer executing a critical section at the same time as readers or another writer. In other words, many of the assumptions (e.g., a variable cannot be modified after a check) in the critical sections are not safe anymore. The read-write locks are used in hypercalls (such as grant-table ones), so a malicious guest could exploit the race. For instance, there is a small window where Xen can leak memory if XENMAPSPACE_grant_table is used concurrently. A malicious guest may be able to leak memory, or cause a hypervisor crash resulting in a Denial of Service (DoS). Information leak and privilege escalation cannot be excluded. | 7.8 |
High |
|
15h55 +00:00 |
An issue was discovered in Xen through 4.12.x allowing x86 AMD HVM guest OS users to cause a denial of service or possibly gain privileges by triggering data-structure access during pagetable-height updates. When running on AMD systems with an IOMMU, Xen attempted to dynamically adapt the number of levels of pagetables (the pagetable height) in the IOMMU according to the guest's address space size. The code to select and update the height had several bugs. Notably, the update was done without taking a lock which is necessary for safe operation. A malicious guest administrator can cause Xen to access data structures while they are being modified, causing Xen to crash. Privilege escalation is thought to be very difficult but cannot be ruled out. Additionally, there is a potential memory leak of 4kb per guest boot, under memory pressure. Only Xen on AMD CPUs is vulnerable. Xen running on Intel CPUs is not vulnerable. ARM systems are not vulnerable. Only systems where guests are given direct access to physical devices are vulnerable. Systems which do not use PCI pass-through are not vulnerable. Only HVM guests can exploit the vulnerability. PV and PVH guests cannot. All versions of Xen with IOMMU support are vulnerable. | 7.2 |
High |
|
15h50 +00:00 |
An issue was discovered in Xen through 4.12.x allowing 32-bit Arm guest OS users to cause a denial of service (out-of-bounds access) because certain bit iteration is mishandled. In a number of places bitmaps are being used by the hypervisor to track certain state. Iteration over all bits involves functions which may misbehave in certain corner cases: On 32-bit Arm accesses to bitmaps with bit a count which is a multiple of 32, an out of bounds access may occur. A malicious guest may cause a hypervisor crash or hang, resulting in a Denial of Service (DoS). All versions of Xen are vulnerable. 32-bit Arm systems are vulnerable. 64-bit Arm systems are not vulnerable. | 6.5 |
Medium |
|
15h50 +00:00 |
An issue was discovered in Xen through 4.12.x allowing x86 guest OS users to cause a denial of service (infinite loop) because certain bit iteration is mishandled. In a number of places bitmaps are being used by the hypervisor to track certain state. Iteration over all bits involves functions which may misbehave in certain corner cases: On x86 accesses to bitmaps with a compile time known size of 64 may incur undefined behavior, which may in particular result in infinite loops. A malicious guest may cause a hypervisor crash or hang, resulting in a Denial of Service (DoS). All versions of Xen are vulnerable. x86 systems with 64 or more nodes are vulnerable (there might not be any such systems that Xen would run on). x86 systems with less than 64 nodes are not vulnerable. | 6.5 |
Medium |
|
15h48 +00:00 |
An issue was discovered in Xen through 4.12.x allowing x86 HVM/PVH guest OS users to cause a denial of service (guest OS crash) because VMX VMEntry checks mishandle a certain case. Please see XSA-260 for background on the MovSS shadow. Please see XSA-156 for background on the need for #DB interception. The VMX VMEntry checks do not like the exact combination of state which occurs when #DB in intercepted, Single Stepping is active, and blocked by STI/MovSS is active, despite this being a legitimate state to be in. The resulting VMEntry failure is fatal to the guest. HVM/PVH guest userspace code may be able to crash the guest, resulting in a guest Denial of Service. All versions of Xen are affected. Only systems supporting VMX hardware virtual extensions (Intel, Cyrix, or Zhaoxin CPUs) are affected. Arm and AMD systems are unaffected. Only HVM/PVH guests are affected. PV guests cannot leverage the vulnerability. | 7.5 |
High |
|
20h03 +00:00 |
An issue was discovered in Xen through 4.12.x allowing attackers to gain host OS privileges via DMA in a situation where an untrusted domain has access to a physical device (and assignable-add is not used), because of an incomplete fix for CVE-2019-18424. XSA-302 relies on the use of libxl's "assignable-add" feature to prepare devices to be assigned to untrusted guests. Unfortunately, this is not considered a strictly required step for device assignment. The PCI passthrough documentation on the wiki describes alternate ways of preparing devices for assignment, and libvirt uses its own ways as well. Hosts where these "alternate" methods are used will still leave the system in a vulnerable state after the device comes back from a guest. An untrusted domain with access to a physical device can DMA into host memory, leading to privilege escalation. Only systems where guests are given direct access to physical devices capable of DMA (PCI pass-through) are vulnerable. Systems which do not use PCI pass-through are not vulnerable. | 6.8 |
Medium |
|
12h38 +00:00 |
An issue was discovered in Xen through 4.12.x allowing attackers to gain host OS privileges via DMA in a situation where an untrusted domain has access to a physical device. This occurs because passed through PCI devices may corrupt host memory after deassignment. When a PCI device is assigned to an untrusted domain, it is possible for that domain to program the device to DMA to an arbitrary address. The IOMMU is used to protect the host from malicious DMA by making sure that the device addresses can only target memory assigned to the guest. However, when the guest domain is torn down, or the device is deassigned, the device is assigned back to dom0, thus allowing any in-flight DMA to potentially target critical host data. An untrusted domain with access to a physical device can DMA into host memory, leading to privilege escalation. Only systems where guests are given direct access to physical devices capable of DMA (PCI pass-through) are vulnerable. Systems which do not use PCI pass-through are not vulnerable. | 6.8 |
Medium |
|
22h00 +00:00 |
An issue was discovered in Xen through 4.12.x allowing Arm domU attackers to cause a denial of service (infinite loop) involving a LoadExcl or StoreExcl operation. | 5.5 |
Medium |
|
22h00 +00:00 |
An issue was discovered in Xen through 4.12.x allowing Arm domU attackers to cause a denial of service (infinite loop) involving a compare-and-exchange operation. | 5.5 |
Medium |
|
22h00 +00:00 |
An issue was discovered in drivers/xen/balloon.c in the Linux kernel before 5.2.3, as used in Xen through 4.12.x, allowing guest OS users to cause a denial of service because of unrestricted resource consumption during the mapping of guest memory, aka CID-6ef36ab967c7. | 6.5 |
Medium |
|
17h00 +00:00 |
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. | 6.5 |
Medium |
|
18h00 +00:00 |
Heap-based buffer overflow in the pcnet_receive function in hw/net/pcnet.c in QEMU allows guest OS administrators to cause a denial of service (instance crash) or possibly execute arbitrary code via a series of packets in loopback mode. | 8.8 |
High |
|
12h00 +00:00 |
The xen_biovec_phys_mergeable function in drivers/xen/biomerge.c in Xen might allow local OS guest users to corrupt block device data streams and consequently obtain sensitive memory information, cause a denial of service, or gain host OS privileges by leveraging incorrect block IO merge-ability calculation. | 8.8 |
High |
|
12h00 +00:00 |
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. | 8.8 |
High |
|
12h00 +00:00 |
arch/x86/mm.c in Xen allows local PV guest OS users to gain host OS privileges via vectors related to map_grant_ref. | 8.8 |
High |
|
20h00 +00:00 |
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. | 7.9 |
High |
|
20h00 +00:00 |
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. | 7.5 |
High |
|
20h00 +00:00 |
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. | 8.8 |
High |
|
20h00 +00:00 |
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. | 7.8 |
High |
|
13h00 +00:00 |
The qemu implementation in libvirt before 1.3.0 and Xen allows local guest OS users to cause a denial of service (host disk consumption) by writing to stdout or stderr. | 6.5 |
Medium |
|
21h00 +00:00 |
Heap-based buffer overflow in QEMU 0.8.2, as used in Xen and possibly other products, allows local users to execute arbitrary code via crafted data in the "net socket listen" option, aka QEMU "net socket" heap overflow. NOTE: some sources have used CVE-2007-1321 to refer to this issue as part of "NE2000 network driver and the socket code," but this is the correct identifier for the individual net socket listen vulnerability. | 7.2 |
2025©
tesweb SA
