Page 7 of 384 results (0.004 seconds)

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

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. • 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://xenbits.xenproject.org/xsa/advisory-382.txt •

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: 5.5EPSS: 0%CPEs: 4EXPL: 0

An issue was discovered in Xen 4.9 through 4.14.x. On Arm, a guest is allowed to control whether memory accesses are bypassing the cache. This means that Xen needs to ensure that all writes (such as the ones during scrubbing) have reached the memory before handing over the page to a guest. Unfortunately, the operation to clean the cache is happening before checking if the page was scrubbed. Therefore there is no guarantee when all the writes will reach the memory. • http://xenbits.xen.org/xsa/advisory-364.html https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/4GELN5E6MDR5KQBJF5M5COUUED3YFZTD https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/EOAJBVAVR6RSCUCHNXPVSNRPSFM7INMP https://www.debian.org/security/2021/dsa-4888 •