CVE-2020-29483
Vulnerability from cvelistv5
Published
2020-12-15 17:15
Modified
2024-08-04 16:55
Severity ?
EPSS score ?
Summary
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.
References
{
"containers": {
"adp": [
{
"providerMetadata": {
"dateUpdated": "2024-08-04T16:55:09.798Z",
"orgId": "af854a3a-2127-422b-91ae-364da2661108",
"shortName": "CVE"
},
"references": [
{
"tags": [
"x_refsource_MISC",
"x_transferred"
],
"url": "https://xenbits.xenproject.org/xsa/advisory-325.txt"
},
{
"name": "DSA-4812",
"tags": [
"vendor-advisory",
"x_refsource_DEBIAN",
"x_transferred"
],
"url": "https://www.debian.org/security/2020/dsa-4812"
},
{
"name": "FEDORA-2020-64859a826b",
"tags": [
"vendor-advisory",
"x_refsource_FEDORA",
"x_transferred"
],
"url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/OBLV6L6Q24PPQ2CRFXDX4Q76KU776GKI/"
},
{
"name": "FEDORA-2020-df772b417b",
"tags": [
"vendor-advisory",
"x_refsource_FEDORA",
"x_transferred"
],
"url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/2C6M6S3CIMEBACH6O7V4H2VDANMO6TVA/"
}
],
"title": "CVE Program Container"
}
],
"cna": {
"affected": [
{
"product": "n/a",
"vendor": "n/a",
"versions": [
{
"status": "affected",
"version": "n/a"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "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\u0027s 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\u0027s 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."
}
],
"problemTypes": [
{
"descriptions": [
{
"description": "n/a",
"lang": "en",
"type": "text"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2020-12-25T02:06:17",
"orgId": "8254265b-2729-46b6-b9e3-3dfca2d5bfca",
"shortName": "mitre"
},
"references": [
{
"tags": [
"x_refsource_MISC"
],
"url": "https://xenbits.xenproject.org/xsa/advisory-325.txt"
},
{
"name": "DSA-4812",
"tags": [
"vendor-advisory",
"x_refsource_DEBIAN"
],
"url": "https://www.debian.org/security/2020/dsa-4812"
},
{
"name": "FEDORA-2020-64859a826b",
"tags": [
"vendor-advisory",
"x_refsource_FEDORA"
],
"url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/OBLV6L6Q24PPQ2CRFXDX4Q76KU776GKI/"
},
{
"name": "FEDORA-2020-df772b417b",
"tags": [
"vendor-advisory",
"x_refsource_FEDORA"
],
"url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/2C6M6S3CIMEBACH6O7V4H2VDANMO6TVA/"
}
],
"x_legacyV4Record": {
"CVE_data_meta": {
"ASSIGNER": "cve@mitre.org",
"ID": "CVE-2020-29483",
"STATE": "PUBLIC"
},
"affects": {
"vendor": {
"vendor_data": [
{
"product": {
"product_data": [
{
"product_name": "n/a",
"version": {
"version_data": [
{
"version_value": "n/a"
}
]
}
}
]
},
"vendor_name": "n/a"
}
]
}
},
"data_format": "MITRE",
"data_type": "CVE",
"data_version": "4.0",
"description": {
"description_data": [
{
"lang": "eng",
"value": "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\u0027s 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\u0027s 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."
}
]
},
"problemtype": {
"problemtype_data": [
{
"description": [
{
"lang": "eng",
"value": "n/a"
}
]
}
]
},
"references": {
"reference_data": [
{
"name": "https://xenbits.xenproject.org/xsa/advisory-325.txt",
"refsource": "MISC",
"url": "https://xenbits.xenproject.org/xsa/advisory-325.txt"
},
{
"name": "DSA-4812",
"refsource": "DEBIAN",
"url": "https://www.debian.org/security/2020/dsa-4812"
},
{
"name": "FEDORA-2020-64859a826b",
"refsource": "FEDORA",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/OBLV6L6Q24PPQ2CRFXDX4Q76KU776GKI/"
},
{
"name": "FEDORA-2020-df772b417b",
"refsource": "FEDORA",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/2C6M6S3CIMEBACH6O7V4H2VDANMO6TVA/"
}
]
}
}
}
},
"cveMetadata": {
"assignerOrgId": "8254265b-2729-46b6-b9e3-3dfca2d5bfca",
"assignerShortName": "mitre",
"cveId": "CVE-2020-29483",
"datePublished": "2020-12-15T17:15:57",
"dateReserved": "2020-12-03T00:00:00",
"dateUpdated": "2024-08-04T16:55:09.798Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.1",
"meta": {
"nvd": "{\"cve\":{\"id\":\"CVE-2020-29483\",\"sourceIdentifier\":\"cve@mitre.org\",\"published\":\"2020-12-15T18:15:15.287\",\"lastModified\":\"2023-11-07T03:21:30.917\",\"vulnStatus\":\"Modified\",\"descriptions\":[{\"lang\":\"en\",\"value\":\"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\u0027s 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\u0027s 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.\"},{\"lang\":\"es\",\"value\":\"Se detect\u00f3 un problema en Xen versiones hasta 4.14.x. Xenstored y los invitados se comunican por medio de una p\u00e1gina de memoria compartida usando un protocolo espec\u00edfico. Cuando un invitado viola este protocolo, xenstored interrumpir\u00e1 la conexi\u00f3n con ese invitado. Desafortunadamente, esto se hace simplemente eliminando al invitado de la administraci\u00f3n interna de xenstored, resultando en las mismas acciones como si el invitado hubiera sido destruido, incluyendo el env\u00edo de un evento @releaseDomain. Los eventos de @releaseDomain no dicen que el invitado ha sido eliminado. Todos los observadores de este evento deben mirar los estados de todos los invitados para encontrar al invitado que ha sido eliminado. Cuando @releaseDomain es generada debido a una violaci\u00f3n del protocolo xenstored del dominio, porque el invitado a\u00fan se est\u00e1 ejecutando, los observadores no reaccionar\u00e1n. M\u00e1s tarde, cuando el invitado sea realmente destruido, xenstored ya no lo tendr\u00e1 almacenado en su base de datos interna, por lo que no m\u00e1s eventos @releaseDomain ser\u00e1n enviados. Esto puede conllevar a un dominio zombi; Las asignaciones de la memoria de ese invitado no ser\u00e1n eliminadas debido a una falta de evento. Este dominio zombie ser\u00e1 limpiado solo despu\u00e9s de que otro dominio sea destruido, ya que eso activar\u00e1 otro evento @releaseDomain. Si el modelo de dispositivo del invitado que viol\u00f3 el protocolo de Xenstore se est\u00e1 ejecutando en un dominio stub, un caso de uso de la memoria previamente liberada podr\u00eda ocurrir en xenstored, despu\u00e9s de haber eliminado al invitado de su base de datos interna, resultando posiblemente en un bloqueo de xenstored. Un invitado malicioso puede bloquear los recursos del host durante un per\u00edodo despu\u00e9s de su propia muerte. Los invitados con un modelo de dispositivo de dominio stub pueden eventualmente bloquearse en xenstored, resultando en una denegaci\u00f3n de servicio m\u00e1s grave (la prevenci\u00f3n de cualquier otra operaci\u00f3n de administraci\u00f3n de dominio). Solo la variante C de Xenstore est\u00e1 afectada; la variante Ocaml no est\u00e1 afectada. Solo los invitados de HVM con un modelo de dispositivo falso pueden causar una DoS grave\"}],\"metrics\":{\"cvssMetricV31\":[{\"source\":\"nvd@nist.gov\",\"type\":\"Primary\",\"cvssData\":{\"version\":\"3.1\",\"vectorString\":\"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:N/I:N/A:H\",\"attackVector\":\"LOCAL\",\"attackComplexity\":\"LOW\",\"privilegesRequired\":\"LOW\",\"userInteraction\":\"NONE\",\"scope\":\"CHANGED\",\"confidentialityImpact\":\"NONE\",\"integrityImpact\":\"NONE\",\"availabilityImpact\":\"HIGH\",\"baseScore\":6.5,\"baseSeverity\":\"MEDIUM\"},\"exploitabilityScore\":2.0,\"impactScore\":4.0}],\"cvssMetricV2\":[{\"source\":\"nvd@nist.gov\",\"type\":\"Primary\",\"cvssData\":{\"version\":\"2.0\",\"vectorString\":\"AV:L/AC:L/Au:N/C:N/I:N/A:C\",\"accessVector\":\"LOCAL\",\"accessComplexity\":\"LOW\",\"authentication\":\"NONE\",\"confidentialityImpact\":\"NONE\",\"integrityImpact\":\"NONE\",\"availabilityImpact\":\"COMPLETE\",\"baseScore\":4.9},\"baseSeverity\":\"MEDIUM\",\"exploitabilityScore\":3.9,\"impactScore\":6.9,\"acInsufInfo\":false,\"obtainAllPrivilege\":false,\"obtainUserPrivilege\":false,\"obtainOtherPrivilege\":false,\"userInteractionRequired\":false}]},\"weaknesses\":[{\"source\":\"nvd@nist.gov\",\"type\":\"Primary\",\"description\":[{\"lang\":\"en\",\"value\":\"CWE-416\"}]}],\"configurations\":[{\"nodes\":[{\"operator\":\"OR\",\"negate\":false,\"cpeMatch\":[{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:xen:xen:*:*:*:*:*:*:*:*\",\"versionEndIncluding\":\"4.14.0\",\"matchCriteriaId\":\"2D769F4A-98C6-4544-AC04-3D8600C17BBB\"}]}]},{\"nodes\":[{\"operator\":\"OR\",\"negate\":false,\"cpeMatch\":[{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:debian:debian_linux:10.0:*:*:*:*:*:*:*\",\"matchCriteriaId\":\"07B237A9-69A3-4A9C-9DA0-4E06BD37AE73\"}]}]},{\"nodes\":[{\"operator\":\"OR\",\"negate\":false,\"cpeMatch\":[{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:fedoraproject:fedora:32:*:*:*:*:*:*:*\",\"matchCriteriaId\":\"36D96259-24BD-44E2-96D9-78CE1D41F956\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:fedoraproject:fedora:33:*:*:*:*:*:*:*\",\"matchCriteriaId\":\"E460AA51-FCDA-46B9-AE97-E6676AA5E194\"}]}]}],\"references\":[{\"url\":\"https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/2C6M6S3CIMEBACH6O7V4H2VDANMO6TVA/\",\"source\":\"cve@mitre.org\"},{\"url\":\"https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/OBLV6L6Q24PPQ2CRFXDX4Q76KU776GKI/\",\"source\":\"cve@mitre.org\"},{\"url\":\"https://www.debian.org/security/2020/dsa-4812\",\"source\":\"cve@mitre.org\",\"tags\":[\"Third Party Advisory\"]},{\"url\":\"https://xenbits.xenproject.org/xsa/advisory-325.txt\",\"source\":\"cve@mitre.org\",\"tags\":[\"Patch\",\"Vendor Advisory\"]}]}}"
}
}
Loading...
Loading...
Sightings
| Author | Source | Type | Date |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
- Confirmed: The vulnerability is confirmed from an analyst perspective.
- Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
- Patched: This vulnerability was successfully patched by the user reporting the sighting.
- Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
- Not confirmed: The user expresses doubt about the veracity of the vulnerability.
- Not patched: This vulnerability was not successfully patched by the user reporting the sighting.