Search Results (Refine Search)
- CPE Product Version: cpe:/o:xen:xen:-
Vuln ID | Summary | CVSS Severity |
---|---|---|
CVE-2023-46837 |
Arm provides multiple helpers to clean & invalidate the cache for a given region. This is, for instance, used when allocating guest memory to ensure any writes (such as the ones during scrubbing) have reached memory before handing over the page to a guest. Unfortunately, the arithmetics in the helpers can overflow and would then result to skip the cache cleaning/invalidation. Therefore there is no guarantee when all the writes will reach the memory. This undefined behavior was meant to be addressed by XSA-437, but the approach was not sufficient. Published: January 05, 2024; 12:15:11 PM -0500 |
V3.1: 3.3 LOW V2.0:(not available) |
CVE-2023-34324 |
Closing of an event channel in the Linux kernel can result in a deadlock. This happens when the close is being performed in parallel to an unrelated Xen console action and the handling of a Xen console interrupt in an unprivileged guest. The closing of an event channel is e.g. triggered by removal of a paravirtual device on the other side. As this action will cause console messages to be issued on the other side quite often, the chance of triggering the deadlock is not neglectable. Note that 32-bit Arm-guests are not affected, as the 32-bit Linux kernel on Arm doesn't use queued-RW-locks, which are required to trigger the issue (on Arm32 a waiting writer doesn't block further readers to get the lock). Published: January 05, 2024; 12:15:08 PM -0500 |
V3.1: 4.9 MEDIUM V2.0:(not available) |
CVE-2023-34323 |
When a transaction is committed, C Xenstored will first check the quota is correct before attempting to commit any nodes. It would be possible that accounting is temporarily negative if a node has been removed outside of the transaction. Unfortunately, some versions of C Xenstored are assuming that the quota cannot be negative and are using assert() to confirm it. This will lead to C Xenstored crash when tools are built without -DNDEBUG (this is the default). Published: January 05, 2024; 12:15:08 PM -0500 |
V3.1: 5.5 MEDIUM V2.0:(not available) |
CVE-2023-34321 |
Arm provides multiple helpers to clean & invalidate the cache for a given region. This is, for instance, used when allocating guest memory to ensure any writes (such as the ones during scrubbing) have reached memory before handing over the page to a guest. Unfortunately, the arithmetics in the helpers can overflow and would then result to skip the cache cleaning/invalidation. Therefore there is no guarantee when all the writes will reach the memory. Published: January 05, 2024; 12:15:08 PM -0500 |
V3.1: 3.3 LOW V2.0:(not available) |
CVE-2023-4949 |
An attacker with local access to a system (either through a disk or external drive) can present a modified XFS partition to grub-legacy in such a way to exploit a memory corruption in grub’s XFS file system implementation. Published: November 10, 2023; 12:15:07 PM -0500 |
V3.1: 6.7 MEDIUM V2.0:(not available) |
CVE-2022-40982 |
Information exposure through microarchitectural state after transient execution in certain vector execution units for some Intel(R) Processors may allow an authenticated user to potentially enable information disclosure via local access. Published: August 10, 2023; 11:15:14 PM -0400 |
V3.1: 6.5 MEDIUM V2.0:(not available) |
CVE-2023-20588 |
A division-by-zero error on some AMD processors can potentially return speculative data resulting in loss of confidentiality. Published: August 08, 2023; 2:15:11 PM -0400 |
V3.1: 5.5 MEDIUM V2.0:(not available) |
CVE-2022-4949 |
The AdSanity plugin for WordPress is vulnerable to arbitrary file uploads due to missing file type validation in the 'ajax_upload' function in versions up to, and including, 1.8.1. This makes it possible for authenticated attackers with Contributor+ level privileges to upload arbitrary files on the affected sites server which makes remote code execution possible. Published: June 06, 2023; 10:15:15 PM -0400 |
V3.1: 8.8 HIGH V2.0:(not available) |
CVE-2022-23824 |
IBPB may not prevent return branch predictions from being specified by pre-IBPB branch targets leading to a potential information disclosure. Published: November 09, 2022; 4:15:13 PM -0500 |
V3.1: 5.5 MEDIUM V2.0:(not available) |
CVE-2022-42323 |
Xenstore: Cooperating guests can create arbitrary numbers of nodes T[his CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] Since the fix of XSA-322 any Xenstore node owned by a removed domain will be modified to be owned by Dom0. This will allow two malicious guests working together to create an arbitrary number of Xenstore nodes. This is possible by domain A letting domain B write into domain A's local Xenstore tree. Domain B can then create many nodes and reboot. The nodes created by domain B will now be owned by Dom0. By repeating this process over and over again an arbitrary number of nodes can be created, as Dom0's number of nodes isn't limited by Xenstore quota. Published: November 01, 2022; 9:15:11 AM -0400 |
V3.1: 5.5 MEDIUM V2.0:(not available) |
CVE-2022-42322 |
Xenstore: Cooperating guests can create arbitrary numbers of nodes T[his CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] Since the fix of XSA-322 any Xenstore node owned by a removed domain will be modified to be owned by Dom0. This will allow two malicious guests working together to create an arbitrary number of Xenstore nodes. This is possible by domain A letting domain B write into domain A's local Xenstore tree. Domain B can then create many nodes and reboot. The nodes created by domain B will now be owned by Dom0. By repeating this process over and over again an arbitrary number of nodes can be created, as Dom0's number of nodes isn't limited by Xenstore quota. Published: November 01, 2022; 9:15:11 AM -0400 |
V3.1: 5.5 MEDIUM V2.0:(not available) |
CVE-2022-42321 |
Xenstore: Guests can crash xenstored via exhausting the stack Xenstored is using recursion for some Xenstore operations (e.g. for deleting a sub-tree of Xenstore nodes). With sufficiently deep nesting levels this can result in stack exhaustion on xenstored, leading to a crash of xenstored. Published: November 01, 2022; 9:15:11 AM -0400 |
V3.1: 6.5 MEDIUM V2.0:(not available) |
CVE-2022-42320 |
Xenstore: Guests can get access to Xenstore nodes of deleted domains Access rights of Xenstore nodes are per domid. When a domain is gone, there might be Xenstore nodes left with access rights containing the domid of the removed domain. This is normally no problem, as those access right entries will be corrected when such a node is written later. There is a small time window when a new domain is created, where the access rights of a past domain with the same domid as the new one will be regarded to be still valid, leading to the new domain being able to get access to a node which was meant to be accessible by the removed domain. For this to happen another domain needs to write the node before the newly created domain is being introduced to Xenstore by dom0. Published: November 01, 2022; 9:15:11 AM -0400 |
V3.1: 7.0 HIGH V2.0:(not available) |
CVE-2022-42318 |
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 Published: November 01, 2022; 9:15:11 AM -0400 |
V3.1: 6.5 MEDIUM V2.0:(not available) |
CVE-2022-42317 |
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 Published: November 01, 2022; 9:15:11 AM -0400 |
V3.1: 6.5 MEDIUM V2.0:(not available) |
CVE-2022-42316 |
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 Published: November 01, 2022; 9:15:11 AM -0400 |
V3.1: 6.5 MEDIUM V2.0:(not available) |
CVE-2022-42315 |
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 Published: November 01, 2022; 9:15:11 AM -0400 |
V3.1: 6.5 MEDIUM V2.0:(not available) |
CVE-2022-42314 |
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 Published: November 01, 2022; 9:15:11 AM -0400 |
V3.1: 6.5 MEDIUM V2.0:(not available) |
CVE-2022-42313 |
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 Published: November 01, 2022; 9:15:11 AM -0400 |
V3.1: 6.5 MEDIUM V2.0:(not available) |
CVE-2022-42312 |
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 Published: November 01, 2022; 9:15:11 AM -0400 |
V3.1: 6.5 MEDIUM V2.0:(not available) |