CVSS: 3.3EPSS: 0%CPEs: 1EXPL: 0CVE-2023-46837 – arm32: The cache may not be properly cleaned/invalidated (take two)
https://notcve.org/view.php?id=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. Arm proporciona múltiples ayudas para limpiar e invalidar el caché de una región determinada. Esto se utiliza, por ejemplo, al asignar memoria de invitado para garantizar que cualquier escritura (como las que se realizan durante la limpieza) haya alcanzado la memoria antes de entregar la página a un invitado. • https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/JFVKWYQFRUU3CAS53THTUKXEOUDWI42G https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/XLL6SQ6IKFYXLYWITYZCRV5IBRK5G35R https://xenbits.xenproject.org/xsa/advisory-447.html • CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer •
CVSS: 4.7EPSS: 0%CPEs: 1EXPL: 0CVE-2023-46836 – x86: BTC/SRSO fixes not fully effective
https://notcve.org/view.php?id=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. Las correcciones para XSA-422 (Branch Type Confusion) y XSA-434 (Speculative Return Stack Overflow) no son seguras para IRQ. Se creía que las mitigaciones siempre operaban en contextos con las IRQ deshabilitadas. • https://xenbits.xenproject.org/xsa/advisory-446.html •
CVSS: 5.5EPSS: 0%CPEs: 1EXPL: 0CVE-2023-46835 – x86/AMD: mismatch in IOMMU quarantine page table levels
https://notcve.org/view.php?id=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. La configuración actual de las tablas de páginas de cuarentena supone que el dominio de cuarentena (dom_io) se ha inicializado con un ancho de dirección de DEFAULT_DOMAIN_ADDRESS_WIDTH (48) y, por lo tanto, 4 niveles de tabla de páginas. Sin embargo, al ser dom_io un dominio PV, los niveles de tablas de páginas IOMMU AMD-Vi se basan en la dirección RAM máxima (conectable en caliente) y, por lo tanto, en sistemas sin RAM por encima de la marca de 512 GB, solo se configuran 3 niveles de tablas de páginas en IOMMU. En sistemas sin RAM por encima del límite de 512 GB, amd_iommu_quarantine_init() configurará tablas de páginas para la página temporal con 4 niveles, mientras que IOMMU se configurará para usar solo 3 niveles, lo que dará como resultado que el último directorio de la tabla de páginas (PDE) se convierta efectivamente en una entrada de la tabla de páginas (PTE) y, por lo tanto, un dispositivo en modo de cuarentena obtiene acceso de escritura a la página destinada a ser una PDE. Debido a esta discrepancia en el nivel de la tabla de páginas, la página receptora a la que el dispositivo tiene acceso de lectura/escritura ya no se borra entre las asignaciones de dispositivos, lo que posiblemente provoque fugas de datos. • https://xenbits.xenproject.org/xsa/advisory-445.html •
CVSS: 5.5EPSS: 0%CPEs: 1EXPL: 0CVE-2023-34328 – x86/AMD: Debug Mask handling
https://notcve.org/view.php?id=CVE-2023-34328
[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. [Este registro de información de la CNA se relaciona con múltiples CVE; el texto explica qué aspectos/vulnerabilidades corresponden a cada CVE.] Las CPU AMD desde ~2014 tienen extensiones a la funcionalidad de depuración x86 normal. Xen admite invitados que utilizan estas extensiones. Desafortunadamente, hay errores en el manejo del estado invitado por parte de Xen, lo que lleva a denegaciones de servicio. 1) CVE-2023-34327: una vCPU HVM puede terminar funcionando en el contexto de un estado de máscara de depuración de vCPU anterior. 2) CVE-2023-34328: una vCPU PV puede colocar un punto de interrupción sobre la GDT en vivo. • https://xenbits.xenproject.org/xsa/advisory-444.html •
CVSS: 5.5EPSS: 0%CPEs: 1EXPL: 0CVE-2023-34327 – x86/AMD: Debug Mask handling
https://notcve.org/view.php?id=CVE-2023-34327
[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. [Este registro de información de la CNA se relaciona con múltiples CVE; el texto explica qué aspectos/vulnerabilidades corresponden a cada CVE.] Las CPU AMD desde ~2014 tienen extensiones a la funcionalidad de depuración x86 normal. Xen admite invitados que utilizan estas extensiones. Desafortunadamente, hay errores en el manejo del estado invitado por parte de Xen, lo que lleva a denegaciones de servicio. 1) CVE-2023-34327: una vCPU HVM puede terminar funcionando en el contexto de un estado de máscara de depuración de vCPU anterior. 2) CVE-2023-34328: una vCPU PV puede colocar un punto de interrupción sobre la GDT en vivo. • https://xenbits.xenproject.org/xsa/advisory-444.html •