An issue was discovered in Xen through 4.13.x, allowing guest OS users to cause a denial of service or possibly gain privileges because of missing memory barriers in read-write unlock paths. The read-write unlock paths don't contain a memory barrier. On Arm, this means a processor is allowed to re-order the memory access with the preceding ones. In other words, the unlock may be seen by another processor before all the memory accesses within the "critical" section. As a consequence, it may be possible to have a writer executing a critical section at the same time as readers or another writer. In other words, many of the assumptions (e.g., a variable cannot be modified after a check) in the critical sections are not safe anymore. The read-write locks are used in hypercalls (such as grant-table ones), so a malicious guest could exploit the race. For instance, there is a small window where Xen can leak memory if XENMAPSPACE_grant_table is used concurrently. A malicious guest may be able to leak memory, or cause a hypervisor crash resulting in a Denial of Service (DoS). Information leak and privilege escalation cannot be excluded.
Default status is the baseline for the product, each version can override it (e.g. patched versions marked unaffected).
| Vendor | Product | Default status | Versions | ||||||
|---|---|---|---|---|---|---|---|---|---|
| n/a | n/a | affected |
|
Configuration 1 [-]
|
Configuration 2 [-]
|
Configuration 3 [-]
|
Configuration 4 [-]
|
No data.
No data.
Project Subscriptions
Advisories
| Source | ID | Title |
|---|---|---|
 Debian DSA |
DSA-4723-1 | xen security update |
 EUVD |
EUVD-2020-4081 | An issue was discovered in Xen through 4.13.x, allowing guest OS users to cause a denial of service or possibly gain privileges because of missing memory barriers in read-write unlock paths. The read-write unlock paths don't contain a memory barrier. On Arm, this means a processor is allowed to re-order the memory access with the preceding ones. In other words, the unlock may be seen by another processor before all the memory accesses within the "critical" section. As a consequence, it may be possible to have a writer executing a critical section at the same time as readers or another writer. In other words, many of the assumptions (e.g., a variable cannot be modified after a check) in the critical sections are not safe anymore. The read-write locks are used in hypercalls (such as grant-table ones), so a malicious guest could exploit the race. For instance, there is a small window where Xen can leak memory if XENMAPSPACE_grant_table is used concurrently. A malicious guest may be able to leak memory, or cause a hypervisor crash resulting in a Denial of Service (DoS). Information leak and privilege escalation cannot be excluded. |
 Ubuntu USN |
USN-5617-1 | Xen vulnerabilities |
Fixes
Solution
No solution given by the vendor.
Workaround
No workaround given by the vendor.
References
History
No history.
Projects
Sign in to view the affected projects.
MITRE
Status: PUBLISHED
Assigner: mitre
Published:
Updated: 2024-08-04T11:41:59.001Z
Reserved: 2020-04-14T00:00:00
Link: CVE-2020-11739
Vulnrichment
No data.
NVD
Status : Modified
Published: 2020-04-14T13:15:12.703
Modified: 2024-11-21T04:58:31.313
Link: CVE-2020-11739
Redhat
OpenCVE Enrichment
No data.
Weaknesses