Filtered by vendor Xen
Subscribe
Total
464 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2025-58145 | 1 Xen | 1 Xen | 2025-11-04 | N/A | 7.5 HIGH |
| [This CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] There are two issues related to the mapping of pages belonging to other domains: For one, an assertion is wrong there, where the case actually needs handling. A NULL pointer de-reference could result on a release build. This is CVE-2025-58144. And then the P2M lock isn't held until a page reference was actually obtained (or the attempt to do so has failed). Otherwise the page can not only change type, but even ownership in between, thus allowing domain boundaries to be violated. This is CVE-2025-58145. | |||||
| CVE-2025-58144 | 1 Xen | 1 Xen | 2025-11-04 | N/A | 7.5 HIGH |
| [This CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] There are two issues related to the mapping of pages belonging to other domains: For one, an assertion is wrong there, where the case actually needs handling. A NULL pointer de-reference could result on a release build. This is CVE-2025-58144. And then the P2M lock isn't held until a page reference was actually obtained (or the attempt to do so has failed). Otherwise the page can not only change type, but even ownership in between, thus allowing domain boundaries to be violated. This is CVE-2025-58145. | |||||
| CVE-2025-58143 | 1 Xen | 1 Xen | 2025-11-04 | N/A | 9.8 CRITICAL |
| [This CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] There are multiple issues related to the handling and accessing of guest memory pages in the viridian code: 1. A NULL pointer dereference in the updating of the reference TSC area. This is CVE-2025-27466. 2. A NULL pointer dereference by assuming the SIM page is mapped when a synthetic timer message has to be delivered. This is CVE-2025-58142. 3. A race in the mapping of the reference TSC page, where a guest can get Xen to free a page while still present in the guest physical to machine (p2m) page tables. This is CVE-2025-58143. | |||||
| CVE-2025-58142 | 1 Xen | 1 Xen | 2025-11-04 | N/A | 9.8 CRITICAL |
| [This CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] There are multiple issues related to the handling and accessing of guest memory pages in the viridian code: 1. A NULL pointer dereference in the updating of the reference TSC area. This is CVE-2025-27466. 2. A NULL pointer dereference by assuming the SIM page is mapped when a synthetic timer message has to be delivered. This is CVE-2025-58142. 3. A race in the mapping of the reference TSC page, where a guest can get Xen to free a page while still present in the guest physical to machine (p2m) page tables. This is CVE-2025-58143. | |||||
| CVE-2025-27466 | 1 Xen | 1 Xen | 2025-11-04 | N/A | 9.8 CRITICAL |
| [This CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] There are multiple issues related to the handling and accessing of guest memory pages in the viridian code: 1. A NULL pointer dereference in the updating of the reference TSC area. This is CVE-2025-27466. 2. A NULL pointer dereference by assuming the SIM page is mapped when a synthetic timer message has to be delivered. This is CVE-2025-58142. 3. A race in the mapping of the reference TSC page, where a guest can get Xen to free a page while still present in the guest physical to machine (p2m) page tables. This is CVE-2025-58143. | |||||
| CVE-2023-34320 | 2 Arm, Xen | 3 Cortex-a77, Cortex-a77 Firmware, Xen | 2025-11-04 | N/A | 5.5 MEDIUM |
| Cortex-A77 cores (r0p0 and r1p0) are affected by erratum 1508412 where software, under certain circumstances, could deadlock a core due to the execution of either a load to device or non-cacheable memory, and either a store exclusive or register read of the Physical Address Register (PAR_EL1) in close proximity. | |||||
| CVE-2023-34319 | 3 Debian, Linux, Xen | 3 Debian Linux, Linux Kernel, Xen | 2025-11-04 | N/A | 7.8 HIGH |
| The fix for XSA-423 added logic to Linux'es netback driver to deal with a frontend splitting a packet in a way such that not all of the headers would come in one piece. Unfortunately the logic introduced there didn't account for the extreme case of the entire packet being split into as many pieces as permitted by the protocol, yet still being smaller than the area that's specially dealt with to keep all (possible) headers together. Such an unusual packet would therefore trigger a buffer overrun in the driver. | |||||
| CVE-2023-46841 | 2 Fedoraproject, Xen | 2 Fedora, Xen | 2025-11-04 | 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-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-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 | 1 Xen | 1 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 | 1 Xen | 1 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 | 2 Intel, Xen | 4 Sgx Dcap, Sgx Psw, Sgx Sdk and 1 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. | |||||