Total
467 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2024-45818 | 1 Xen | 1 Xen | 2025-05-20 | N/A | 6.5 MEDIUM |
| The hypervisor contains code to accelerate VGA memory accesses for HVM guests, when the (virtual) VGA is in "standard" mode. Locking involved there has an unusual discipline, leaving a lock acquired past the return from the function that acquired it. This behavior results in a problem when emulating an instruction with two memory accesses, both of which touch VGA memory (plus some further constraints which aren't relevant here). When emulating the 2nd access, the lock that is already being held would be attempted to be re-acquired, resulting in a deadlock. This deadlock was already found when the code was first introduced, but was analysed incorrectly and the fix was incomplete. Analysis in light of the new finding cannot find a way to make the existing locking discipline work. In staging, this logic has all been removed because it was discovered to be accidentally disabled since Xen 4.7. Therefore, we are fixing the locking problem by backporting the removal of most of the feature. Note that even with the feature disabled, the lock would still be acquired for any accesses to the VGA MMIO region. | |||||
| CVE-2023-46841 | 2 Fedoraproject, Xen | 2 Fedora, Xen | 2025-05-12 | N/A | 6.5 MEDIUM |
| Recent x86 CPUs offer functionality named Control-flow Enforcement Technology (CET). A sub-feature of this are Shadow Stacks (CET-SS). CET-SS is a hardware feature designed to protect against Return Oriented Programming attacks. When enabled, traditional stacks holding both data and return addresses are accompanied by so called "shadow stacks", holding little more than return addresses. Shadow stacks aren't writable by normal instructions, and upon function returns their contents are used to check for possible manipulation of a return address coming from the traditional stack. In particular certain memory accesses need intercepting by Xen. In various cases the necessary emulation involves kind of replaying of the instruction. Such replaying typically involves filling and then invoking of a stub. Such a replayed instruction may raise an exceptions, which is expected and dealt with accordingly. Unfortunately the interaction of both of the above wasn't right: Recovery involves removal of a call frame from the (traditional) stack. The counterpart of this operation for the shadow stack was missing. | |||||
| CVE-2022-42315 | 3 Debian, Fedoraproject, Xen | 3 Debian Linux, Fedora, Xen | 2025-05-06 | N/A | 6.5 MEDIUM |
| Xenstore: guests can let run xenstored out of memory T[his CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] Malicious guests can cause xenstored to allocate vast amounts of memory, eventually resulting in a Denial of Service (DoS) of xenstored. There are multiple ways how guests can cause large memory allocations in xenstored: - - by issuing new requests to xenstored without reading the responses, causing the responses to be buffered in memory - - by causing large number of watch events to be generated via setting up multiple xenstore watches and then e.g. deleting many xenstore nodes below the watched path - - by creating as many nodes as allowed with the maximum allowed size and path length in as many transactions as possible - - by accessing many nodes inside a transaction | |||||
| CVE-2022-42314 | 3 Debian, Fedoraproject, Xen | 3 Debian Linux, Fedora, Xen | 2025-05-06 | N/A | 6.5 MEDIUM |
| Xenstore: guests can let run xenstored out of memory T[his CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] Malicious guests can cause xenstored to allocate vast amounts of memory, eventually resulting in a Denial of Service (DoS) of xenstored. There are multiple ways how guests can cause large memory allocations in xenstored: - - by issuing new requests to xenstored without reading the responses, causing the responses to be buffered in memory - - by causing large number of watch events to be generated via setting up multiple xenstore watches and then e.g. deleting many xenstore nodes below the watched path - - by creating as many nodes as allowed with the maximum allowed size and path length in as many transactions as possible - - by accessing many nodes inside a transaction | |||||
| CVE-2022-42313 | 3 Debian, Fedoraproject, Xen | 3 Debian Linux, Fedora, Xen | 2025-05-06 | N/A | 6.5 MEDIUM |
| Xenstore: guests can let run xenstored out of memory T[his CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] Malicious guests can cause xenstored to allocate vast amounts of memory, eventually resulting in a Denial of Service (DoS) of xenstored. There are multiple ways how guests can cause large memory allocations in xenstored: - - by issuing new requests to xenstored without reading the responses, causing the responses to be buffered in memory - - by causing large number of watch events to be generated via setting up multiple xenstore watches and then e.g. deleting many xenstore nodes below the watched path - - by creating as many nodes as allowed with the maximum allowed size and path length in as many transactions as possible - - by accessing many nodes inside a transaction | |||||
| CVE-2022-42312 | 3 Debian, Fedoraproject, Xen | 3 Debian Linux, Fedora, Xen | 2025-05-06 | N/A | 6.5 MEDIUM |
| Xenstore: guests can let run xenstored out of memory T[his CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] Malicious guests can cause xenstored to allocate vast amounts of memory, eventually resulting in a Denial of Service (DoS) of xenstored. There are multiple ways how guests can cause large memory allocations in xenstored: - - by issuing new requests to xenstored without reading the responses, causing the responses to be buffered in memory - - by causing large number of watch events to be generated via setting up multiple xenstore watches and then e.g. deleting many xenstore nodes below the watched path - - by creating as many nodes as allowed with the maximum allowed size and path length in as many transactions as possible - - by accessing many nodes inside a transaction | |||||
| CVE-2022-42311 | 3 Debian, Fedoraproject, Xen | 3 Debian Linux, Fedora, Xen | 2025-05-06 | N/A | 6.5 MEDIUM |
| Xenstore: guests can let run xenstored out of memory T[his CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] Malicious guests can cause xenstored to allocate vast amounts of memory, eventually resulting in a Denial of Service (DoS) of xenstored. There are multiple ways how guests can cause large memory allocations in xenstored: - - by issuing new requests to xenstored without reading the responses, causing the responses to be buffered in memory - - by causing large number of watch events to be generated via setting up multiple xenstore watches and then e.g. deleting many xenstore nodes below the watched path - - by creating as many nodes as allowed with the maximum allowed size and path length in as many transactions as possible - - by accessing many nodes inside a transaction | |||||
| CVE-2022-42327 | 2 Fedoraproject, Xen | 2 Fedora, Xen | 2025-05-05 | N/A | 7.1 HIGH |
| x86: unintended memory sharing between guests On Intel systems that support the "virtualize APIC accesses" feature, a guest can read and write the global shared xAPIC page by moving the local APIC out of xAPIC mode. Access to this shared page bypasses the expected isolation that should exist between two guests. | |||||
| CVE-2022-42317 | 3 Debian, Fedoraproject, Xen | 3 Debian Linux, Fedora, Xen | 2025-05-05 | N/A | 6.5 MEDIUM |
| Xenstore: guests can let run xenstored out of memory T[his CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] Malicious guests can cause xenstored to allocate vast amounts of memory, eventually resulting in a Denial of Service (DoS) of xenstored. There are multiple ways how guests can cause large memory allocations in xenstored: - - by issuing new requests to xenstored without reading the responses, causing the responses to be buffered in memory - - by causing large number of watch events to be generated via setting up multiple xenstore watches and then e.g. deleting many xenstore nodes below the watched path - - by creating as many nodes as allowed with the maximum allowed size and path length in as many transactions as possible - - by accessing many nodes inside a transaction | |||||
| CVE-2022-42316 | 3 Debian, Fedoraproject, Xen | 3 Debian Linux, Fedora, Xen | 2025-05-05 | N/A | 6.5 MEDIUM |
| Xenstore: guests can let run xenstored out of memory T[his CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] Malicious guests can cause xenstored to allocate vast amounts of memory, eventually resulting in a Denial of Service (DoS) of xenstored. There are multiple ways how guests can cause large memory allocations in xenstored: - - by issuing new requests to xenstored without reading the responses, causing the responses to be buffered in memory - - by causing large number of watch events to be generated via setting up multiple xenstore watches and then e.g. deleting many xenstore nodes below the watched path - - by creating as many nodes as allowed with the maximum allowed size and path length in as many transactions as possible - - by accessing many nodes inside a transaction | |||||
| CVE-2022-42318 | 3 Debian, Fedoraproject, Xen | 3 Debian Linux, Fedora, Xen | 2025-05-05 | N/A | 6.5 MEDIUM |
| Xenstore: guests can let run xenstored out of memory T[his CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] Malicious guests can cause xenstored to allocate vast amounts of memory, eventually resulting in a Denial of Service (DoS) of xenstored. There are multiple ways how guests can cause large memory allocations in xenstored: - - by issuing new requests to xenstored without reading the responses, causing the responses to be buffered in memory - - by causing large number of watch events to be generated via setting up multiple xenstore watches and then e.g. deleting many xenstore nodes below the watched path - - by creating as many nodes as allowed with the maximum allowed size and path length in as many transactions as possible - - by accessing many nodes inside a transaction | |||||
| CVE-2022-21166 | 5 Debian, Fedoraproject, Intel and 2 more | 7 Debian Linux, Fedora, Sgx Dcap and 4 more | 2025-05-05 | 2.1 LOW | 5.5 MEDIUM |
| Incomplete cleanup in specific special register write operations for some Intel(R) Processors may allow an authenticated user to potentially enable information disclosure via local access. | |||||
| CVE-2022-21127 | 3 Debian, Intel, Xen | 5 Debian Linux, Sgx Dcap, Sgx Psw and 2 more | 2025-05-05 | 2.1 LOW | 5.5 MEDIUM |
| Incomplete cleanup in specific special register read operations for some Intel(R) Processors may allow an authenticated user to potentially enable information disclosure via local access. | |||||
| CVE-2022-21125 | 5 Debian, Fedoraproject, Intel and 2 more | 7 Debian Linux, Fedora, Sgx Dcap and 4 more | 2025-05-05 | 2.1 LOW | 5.5 MEDIUM |
| Incomplete cleanup of microarchitectural fill buffers on some Intel(R) Processors may allow an authenticated user to potentially enable information disclosure via local access. | |||||
| CVE-2022-21123 | 5 Debian, Fedoraproject, Intel and 2 more | 7 Debian Linux, Fedora, Sgx Dcap and 4 more | 2025-05-05 | 2.1 LOW | 5.5 MEDIUM |
| Incomplete cleanup of multi-core shared buffers for some Intel(R) Processors may allow an authenticated user to potentially enable information disclosure via local access. | |||||
| CVE-2022-42326 | 3 Debian, Fedoraproject, Xen | 3 Debian Linux, Fedora, Xen | 2025-05-05 | N/A | 5.5 MEDIUM |
| Xenstore: Guests can create arbitrary number of nodes via transactions T[his CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] In case a node has been created in a transaction and it is later deleted in the same transaction, the transaction will be terminated with an error. As this error is encountered only when handling the deleted node at transaction finalization, the transaction will have been performed partially and without updating the accounting information. This will enable a malicious guest to create arbitrary number of nodes. | |||||
| CVE-2015-8104 | 5 Canonical, Debian, Linux and 2 more | 6 Ubuntu Linux, Debian Linux, Linux Kernel and 3 more | 2025-04-23 | 4.7 MEDIUM | 10.0 CRITICAL |
| The KVM subsystem in the Linux kernel through 4.2.6, and Xen 4.3.x through 4.6.x, allows guest OS users to cause a denial of service (host OS panic or hang) by triggering many #DB (aka Debug) exceptions, related to svm.c. | |||||
| CVE-2017-17044 | 1 Xen | 1 Xen | 2025-04-20 | 4.9 MEDIUM | 6.5 MEDIUM |
| An issue was discovered in Xen through 4.9.x allowing HVM guest OS users to cause a denial of service (infinite loop and host OS hang) by leveraging the mishandling of Populate on Demand (PoD) errors. | |||||
| CVE-2016-9817 | 1 Xen | 1 Xen | 2025-04-20 | 4.9 MEDIUM | 6.5 MEDIUM |
| Xen through 4.7.x allows local ARM guest OS users to cause a denial of service (host crash) via vectors involving a (1) data or (2) prefetch abort with the ESR_EL2.EA bit set. | |||||
| CVE-2017-15590 | 1 Xen | 1 Xen | 2025-04-20 | 4.6 MEDIUM | 8.8 HIGH |
| An issue was discovered in Xen through 4.9.x allowing x86 guest OS users to cause a denial of service (hypervisor crash) or possibly gain privileges because MSI mapping was mishandled. | |||||