An issue was discovered in Xen through 4.14.x. Xenstored and guests communicate via a shared memory page using a specific protocol. When a guest violates this protocol, xenstored will drop the connection to that guest. Unfortunately, this is done by just removing the guest from xenstored's internal management, resulting in the same actions as if the guest had been destroyed, including sending an @releaseDomain event. @releaseDomain events do not say that the guest has been removed. All watchers of this event must look at the states of all guests to find the guest that has been removed. When an @releaseDomain is generated due to a domain xenstored protocol violation, because the guest is still running, the watchers will not react. Later, when the guest is actually destroyed, xenstored will no longer have it stored in its internal data base, so no further @releaseDomain event will be sent. This can lead to a zombie domain; memory mappings of that guest's memory will not be removed, due to the missing event. This zombie domain will be cleaned up only after another domain is destroyed, as that will trigger another @releaseDomain event. If the device model of the guest that violated the Xenstore protocol is running in a stub-domain, a use-after-free case could happen in xenstored, after having removed the guest from its internal data base, possibly resulting in a crash of xenstored. A malicious guest can block resources of the host for a period after its own death. Guests with a stub domain device model can eventually crash xenstored, resulting in a more serious denial of service (the prevention of any further domain management operations). Only the C variant of Xenstore is affected; the Ocaml variant is not affected. Only HVM guests with a stubdom device model can cause a serious DoS.
Published 2020-12-15 18:15:15
Updated 2021-03-16 12:58:42
Source MITRE
View at NVD,   CVE.org
Vulnerability category: Memory CorruptionDenial of service

Products affected by CVE-2020-29483

Exploit prediction scoring system (EPSS) score for CVE-2020-29483

0.04%
Probability of exploitation activity in the next 30 days EPSS Score History
~ 6 %
Percentile, the proportion of vulnerabilities that are scored at or less

CVSS scores for CVE-2020-29483

Base Score Base Severity CVSS Vector Exploitability Score Impact Score Score Source First Seen
4.9
MEDIUM AV:L/AC:L/Au:N/C:N/I:N/A:C
3.9
6.9
NIST
6.5
MEDIUM CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:N/I:N/A:H
2.0
4.0
NIST

CWE ids for CVE-2020-29483

  • The product reuses or references memory after it has been freed. At some point afterward, the memory may be allocated again and saved in another pointer, while the original pointer references a location somewhere within the new allocation. Any operations using the original pointer are no longer valid because the memory "belongs" to the code that operates on the new pointer.
    Assigned by: nvd@nist.gov (Primary)

References for CVE-2020-29483

Jump to
This web site uses cookies for managing your session, storing preferences, website analytics and additional purposes described in our privacy policy.
By using this web site you are agreeing to CVEdetails.com terms of use!