CVE-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 •
CVE-2021-28690
https://notcve.org/view.php?id=CVE-2021-28690
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. x86: Las protecciones TSX Async Abort no son restauradas después de S3. Este problema está relacionado con una vulnerabilidad de seguridad especulativa TSX Async Abort. • https://security.gentoo.org/glsa/202107-30 https://xenbits.xenproject.org/xsa/advisory-377.txt •
CVE-2021-28692
https://notcve.org/view.php?id=CVE-2021-28692
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 •
CVE-2021-28687
https://notcve.org/view.php?id=CVE-2021-28687
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. • https://security.gentoo.org/glsa/202107-30 https://xenbits.xenproject.org/xsa/advisory-368.txt • CWE-909: Missing Initialization of Resource •
CVE-2021-28689
https://notcve.org/view.php?id=CVE-2021-28689
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 •