CVSS: 8.6EPSS: 0%CPEs: 4EXPL: 0CVE-2022-42333
https://notcve.org/view.php?id=CVE-2022-42333
x86/HVM pinned cache attributes mis-handling T[his CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] To allow cachability control for HVM guests with passed through devices, an interface exists to explicitly override defaults which would otherwise be put in place. While not exposed to the affected guests themselves, the interface specifically exists for domains controlling such guests. This interface may therefore be used by not fully privileged entities, e.g. qemu running deprivileged in Dom0 or qemu running in a so called stub-domain. With this exposure it is an issue that - the number of the such controlled regions was unbounded (CVE-2022-42333), - installation and removal of such regions was not properly serialized (CVE-2022-42334). • http://www.openwall.com/lists/oss-security/2023/03/21/2 http://xenbits.xen.org/xsa/advisory-428.html https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/5L6PM4RE7MUE6OWA32ZVOXCP235RM2TM https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/APBMS2Q6746AXAFAITNJMGBNFGNMVLWR https://security.gentoo.org/glsa/202402-07 https://www.debian.org/security/2023/dsa-5378 https://xenbits.xenproject.org/xsa/advisory-428.txt • CWE-770: Allocation of Resources Without Limits or Throttling •
CVSS: 6.5EPSS: 0%CPEs: 4EXPL: 0CVE-2022-42334
https://notcve.org/view.php?id=CVE-2022-42334
x86/HVM pinned cache attributes mis-handling T[his CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] To allow cachability control for HVM guests with passed through devices, an interface exists to explicitly override defaults which would otherwise be put in place. While not exposed to the affected guests themselves, the interface specifically exists for domains controlling such guests. This interface may therefore be used by not fully privileged entities, e.g. qemu running deprivileged in Dom0 or qemu running in a so called stub-domain. With this exposure it is an issue that - the number of the such controlled regions was unbounded (CVE-2022-42333), - installation and removal of such regions was not properly serialized (CVE-2022-42334). • http://www.openwall.com/lists/oss-security/2023/03/21/2 http://xenbits.xen.org/xsa/advisory-428.html https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/5L6PM4RE7MUE6OWA32ZVOXCP235RM2TM https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/APBMS2Q6746AXAFAITNJMGBNFGNMVLWR https://security.gentoo.org/glsa/202402-07 https://www.debian.org/security/2023/dsa-5378 https://xenbits.xenproject.org/xsa/advisory-428.txt • CWE-770: Allocation of Resources Without Limits or Throttling •
CVSS: 7.5EPSS: 0%CPEs: 1EXPL: 0CVE-2022-42330
https://notcve.org/view.php?id=CVE-2022-42330
Guests can cause Xenstore crash via soft reset When a guest issues a "Soft Reset" (e.g. for performing a kexec) the libxl based Xen toolstack will normally perform a XS_RELEASE Xenstore operation. Due to a bug in xenstored this can result in a crash of xenstored. Any other use of XS_RELEASE will have the same impact. Los invitados pueden provocar un fallo de Xenstore mediante un reinicio por software Cuando un invitado emite un "Reinicio por software" (por ejemplo, para realizar un kexec), la pila de herramientas de Xen basada en libxl normalmente realizará una operación XS_RELEASE de Xenstore. Debido a un error en xenstored, esto puede provocar un fallo de xenstored. • https://security.gentoo.org/glsa/202402-07 https://xenbits.xenproject.org/xsa/advisory-425.txt •
CVSS: 7.0EPSS: 0%CPEs: 1EXPL: 0CVE-2021-28703
https://notcve.org/view.php?id=CVE-2021-28703
grant table v2 status pages may remain accessible after de-allocation (take two) 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://security.gentoo.org/glsa/202402-07 https://xenbits.xenproject.org/xsa/advisory-387.txt •