Page 4 of 247 results (0.022 seconds)

CVSS: 5.5EPSS: 0%CPEs: 5EXPL: 0

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. bucles de larga duración en el manejo de la tabla de concesiones. • http://www.openwall.com/lists/oss-security/2021/09/01/2 https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/2VQCFAPBNGBBAOMJZG6QBREOG5IIDZID https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/FZCNPSRPGFCQRYE2BI4D4Q4SCE56ANV2 https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/LPRVHW4J4ZCPPOHZEWP5MOJT7XDGFFPJ https://security.gentoo.org/glsa/202208-23 https://www.debian.org/security/2021/dsa-4977 https:/&#x • CWE-835: Loop with Unreachable Exit Condition ('Infinite Loop') •

CVSS: 7.1EPSS: 0%CPEs: 1EXPL: 0

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. • https://security.gentoo.org/glsa/202107-30 https://xenbits.xenproject.org/xsa/advisory-373.txt • CWE-269: Improper Privilege Management •

CVSS: 5.5EPSS: 0%CPEs: 1EXPL: 0

x86: Speculative vulnerabilities with bare (non-shim) 32-bit PV guests 32-bit x86 PV guest kernels run in ring 1. At the time when Xen was developed, this area of the i386 architecture was rarely used, which is why Xen was able to use it to implement paravirtualisation, Xen's novel approach to virtualization. In AMD64, Xen had to use a different implementation approach, so Xen does not use ring 1 to support 64-bit guests. With the focus now being on 64-bit systems, and the availability of explicit hardware support for virtualization, fixing speculation issues in ring 1 is not a priority for processor companies. Indirect Branch Restricted Speculation (IBRS) is an architectural x86 extension put together to combat speculative execution sidechannel attacks, including Spectre v2. • https://xenbits.xenproject.org/xsa/advisory-370.txt • CWE-212: Improper Removal of Sensitive Information Before Storage or Transfer •

CVSS: 7.8EPSS: 0%CPEs: 2EXPL: 0

An issue was discovered in Xen through 4.11.x, allowing x86 Intel HVM guest OS users to achieve unintended read/write DMA access, and possibly cause a denial of service (host OS crash) or gain privileges. This occurs because a backport missed a flush, and thus IOMMU updates were not always correct. NOTE: this issue exists because of an incomplete fix for CVE-2020-15565. Se detectó un problema en Xen versiones hasta 4.11.x, permitiendo a usuarios del Sistema Operativo invitado x86 Intel HVM obtener acceso DMA de lectura y escritura no previsto y posiblemente causar una denegación de servicio (bloqueo del Sistema Operativo host) o alcanzar privilegios. Esto ocurre porque un backport no se descargó y, por lo tanto, las actualizaciones de IOMMU no siempre fueron correctas. • http://www.openwall.com/lists/oss-security/2021/02/23/1 http://xenbits.xen.org/xsa/advisory-366.html https://www.debian.org/security/2021/dsa-4888 https://xenbits.xen.org/xsa/advisory-366.html •

CVSS: 6.0EPSS: 0%CPEs: 4EXPL: 0

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. • https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/2C6M6S3CIMEBACH6O7V4H2VDANMO6TVA https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/OBLV6L6Q24PPQ2CRFXDX4Q76KU776GKI https://security.gentoo.org/glsa/202107-30 https://www.debian.org/security/2020/dsa-4812 https://xenbits.xenproject.org/xsa/advisory-352.html • CWE-770: Allocation of Resources Without Limits or Throttling •