CVSS: 8.8EPSS: 0%CPEs: 4EXPL: 0CVE-2021-28708
https://notcve.org/view.php?id=CVE-2021-28708
PoD operations on misaligned GFNs T[his CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] x86 HVM and PVH guests may be started in populate-on-demand (PoD) mode, to provide a way for them to later easily have more memory assigned. Guests are permitted to control certain P2M aspects of individual pages via hypercalls. These hypercalls may act on ranges of pages specified via page orders (resulting in a power-of-2 number of pages). The implementation of some of these hypercalls for PoD does not enforce the base page frame number to be suitably aligned for the specified order, yet some code involved in PoD handling actually makes such an assumption. These operations are XENMEM_decrease_reservation (CVE-2021-28704) and XENMEM_populate_physmap (CVE-2021-28707), the latter usable only by domains controlling the guest, i.e. a de-privileged qemu or a stub domain. • https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/I7ZGWVVRI4XY2XSTBI3XEMWBXPDVX6OT https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/PXUI4VMD52CH3T7YXAG3J2JW7ZNN3SXF https://security.gentoo.org/glsa/202402-07 https://www.debian.org/security/2021/dsa-5017 https://xenbits.xenproject.org/xsa/advisory-388.txt •
CVSS: 8.8EPSS: 0%CPEs: 2EXPL: 0CVE-2021-28710
https://notcve.org/view.php?id=CVE-2021-28710
certain VT-d IOMMUs may not work in shared page table mode For efficiency reasons, address translation control structures (page tables) may (and, on suitable hardware, by default will) be shared between CPUs, for second-level translation (EPT), and IOMMUs. These page tables are presently set up to always be 4 levels deep. However, an IOMMU may require the use of just 3 page table levels. In such a configuration the lop level table needs to be stripped before inserting the root table's address into the hardware pagetable base register. When sharing page tables, Xen erroneously skipped this stripping. • https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/I7ZGWVVRI4XY2XSTBI3XEMWBXPDVX6OT https://security.gentoo.org/glsa/202208-23 https://xenbits.xenproject.org/xsa/advisory-390.txt • CWE-269: Improper Privilege Management •
CVSS: 7.6EPSS: 0%CPEs: 5EXPL: 0CVE-2021-28702
https://notcve.org/view.php?id=CVE-2021-28702
PCI devices with RMRRs not deassigned correctly Certain PCI devices in a system might be assigned Reserved Memory Regions (specified via Reserved Memory Region Reporting, "RMRR"). These are typically used for platform tasks such as legacy USB emulation. If such a device is passed through to a guest, then on guest shutdown the device is not properly deassigned. The IOMMU configuration for these devices which are not properly deassigned ends up pointing to a freed data structure, including the IO Pagetables. Subsequent DMA or interrupts from the device will have unpredictable behaviour, ranging from IOMMU faults to memory corruption. • http://www.openwall.com/lists/oss-security/2021/10/07/2 https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/2OIHEJ3R3EH5DYI2I5UMD2ULJ2ELA3EX https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/FDPRMOBBLS74ONYP3IXZZXSTLKR7GRQB https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/TRAWV6PO2KUGVZTESERECOBUBZ6X45I7 https://security.gentoo.org/glsa/202208-23 https://www.debian.org/security/2021/dsa-5017 https:/&#x • CWE-269: Improper Privilege Management •
CVSS: 7.8EPSS: 0%CPEs: 5EXPL: 0CVE-2021-28697
https://notcve.org/view.php?id=CVE-2021-28697
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. • 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-379.txt • CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition') •
CVSS: 5.5EPSS: 0%CPEs: 2EXPL: 0CVE-2021-28693
https://notcve.org/view.php?id=CVE-2021-28693
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. xen/arm: Los módulos de arranque no se limpian. El cargador de arranque cargará los módulos de arranque (por ejemplo, kernel, initramfs...) en un área temporal antes de que sean copiados por Xen a la memoria de cada dominio. Para asegurar que no se filtren datos confidenciales de los módulos, Xen debe "scrub" antes de entregar la página al asignador. • https://security.gentoo.org/glsa/202107-30 https://xenbits.xenproject.org/xsa/advisory-372.txt •