{"containers": {"cna": {"affected": [{"product": "xen", "vendor": "Xen", "versions": [{"status": "affected", "version": "xen-unstable"}]}, {"product": "xen", "vendor": "Xen", "versions": [{"lessThan": "4.12", "status": "unknown", "version": "unspecified", "versionType": "custom"}, {"lessThan": "unspecified", "status": "affected", "version": "4.12.x", "versionType": "custom"}, {"lessThan": "unspecified", "status": "unaffected", "version": "next of 4.13.x", "versionType": "custom"}]}, {"product": "xen", "vendor": "Xen", "versions": [{"status": "affected", "version": "4.14.x"}]}], "credits": [{"lang": "en", "value": "{'credit_data': {'description': {'description_data': [{'lang': 'eng', 'value': 'This issue was discovered by Olaf Hering.'}]}}}"}], "descriptions": [{"lang": "en", "value": "HVM soft-reset crashes toolstack libxl requires all data structures passed across its public interface to be initialized before use and disposed of afterwards by calling a specific set of functions. Many internal data structures also require this initialize / dispose discipline, but not all of them. When the \"soft reset\" feature was implemented, the libxl__domain_suspend_state structure didn't require any initialization or disposal. At some point later, an initialization function was introduced for the structure; but the \"soft reset\" path wasn't refactored to call the initialization function. When a guest nwo initiates a \"soft reboot\", uninitialized data structure leads to an assert() when later code finds the structure in an unexpected state. The effect of this is to crash the process monitoring the guest. How this affects the system depends on the structure of the toolstack. For xl, this will have no security-relevant effect: every VM has its own independent monitoring process, which contains no state. The domain in question will hang in a crashed state, but can be destroyed by `xl destroy` just like any other non-cooperating domain. For daemon-based toolstacks linked against libxl, such as libvirt, this will crash the toolstack, losing the state of any in-progress operations (localized DoS), and preventing further administrator operations unless the daemon is configured to restart automatically (system-wide DoS). If crashes \"leak\" resources, then repeated crashes could use up resources, also causing a system-wide DoS."}], "metrics": [{"other": {"content": {"description": {"description_data": [{"lang": "eng", "value": "A malicious guest can crash the management daemon, leading to at least\na localized, possibly system-wide denial-of-service."}]}}, "type": "unknown"}}], "problemTypes": [{"descriptions": [{"description": "unknown", "lang": "en", "type": "text"}]}], "providerMetadata": {"dateUpdated": "2021-07-12T04:06:39", "orgId": "23aa2041-22e1-471f-9209-9b7396fa234f", "shortName": "XEN"}, "references": [{"tags": ["x_refsource_MISC"], "url": "https://xenbits.xenproject.org/xsa/advisory-368.txt"}, {"name": "GLSA-202107-30", "tags": ["vendor-advisory", "x_refsource_GENTOO"], "url": "https://security.gentoo.org/glsa/202107-30"}], "x_legacyV4Record": {"CVE_data_meta": {"ASSIGNER": "security@xen.org", "ID": "CVE-2021-28687", "STATE": "PUBLIC"}, "affects": {"vendor": {"vendor_data": [{"product": {"product_data": [{"product_name": "xen", "version": {"version_data": [{"version_value": "xen-unstable"}]}}, {"product_name": "xen", "version": {"version_data": [{"version_affected": "?<", "version_value": "4.12"}, {"version_affected": ">=", "version_value": "4.12.x"}, {"version_affected": "!>", "version_value": "4.13.x"}]}}, {"product_name": "xen", "version": {"version_data": [{"version_value": "4.14.x"}]}}]}, "vendor_name": "Xen"}]}}, "configuration": {"configuration_data": {"description": {"description_data": [{"lang": "eng", "value": "Only Xen versions 4.12 through 4.14 are affected. Earlier versions\nare not affected.\n\nThe issue affects only systems with a guest monitoring process, which\nis linked against libxl, and which is important other than simply for\nthe functioning of one particular guest. libvirt is one common\ntoolstack affected. Systems using the `xl` command-line tool should\ngenerally suffer no security-relevant effects.\n\nThe xapi toolstack does not currently link against libxl, and so is\nnot affected."}]}}}, "credit": {"credit_data": {"description": {"description_data": [{"lang": "eng", "value": "This issue was discovered by Olaf Hering."}]}}}, "data_format": "MITRE", "data_type": "CVE", "data_version": "4.0", "description": {"description_data": [{"lang": "eng", "value": "HVM soft-reset crashes toolstack libxl requires all data structures passed across its public interface to be initialized before use and disposed of afterwards by calling a specific set of functions. Many internal data structures also require this initialize / dispose discipline, but not all of them. When the \"soft reset\" feature was implemented, the libxl__domain_suspend_state structure didn't require any initialization or disposal. At some point later, an initialization function was introduced for the structure; but the \"soft reset\" path wasn't refactored to call the initialization function. When a guest nwo initiates a \"soft reboot\", uninitialized data structure leads to an assert() when later code finds the structure in an unexpected state. The effect of this is to crash the process monitoring the guest. How this affects the system depends on the structure of the toolstack. For xl, this will have no security-relevant effect: every VM has its own independent monitoring process, which contains no state. The domain in question will hang in a crashed state, but can be destroyed by `xl destroy` just like any other non-cooperating domain. For daemon-based toolstacks linked against libxl, such as libvirt, this will crash the toolstack, losing the state of any in-progress operations (localized DoS), and preventing further administrator operations unless the daemon is configured to restart automatically (system-wide DoS). If crashes \"leak\" resources, then repeated crashes could use up resources, also causing a system-wide DoS."}]}, "impact": {"impact_data": {"description": {"description_data": [{"lang": "eng", "value": "A malicious guest can crash the management daemon, leading to at least\na localized, possibly system-wide denial-of-service."}]}}}, "problemtype": {"problemtype_data": [{"description": [{"lang": "eng", "value": "unknown"}]}]}, "references": {"reference_data": [{"name": "https://xenbits.xenproject.org/xsa/advisory-368.txt", "refsource": "MISC", "url": "https://xenbits.xenproject.org/xsa/advisory-368.txt"}, {"name": "GLSA-202107-30", "refsource": "GENTOO", "url": "https://security.gentoo.org/glsa/202107-30"}]}, "workaround": {"workaround_data": {"description": {"description_data": [{"lang": "eng", "value": "Ensuring that any management daemons are restarted automatically after\na crash will partially mitigate the issue."}]}}}}}, "adp": [{"providerMetadata": {"orgId": "af854a3a-2127-422b-91ae-364da2661108", "shortName": "CVE", "dateUpdated": "2024-08-03T21:47:33.121Z"}, "title": "CVE Program Container", "references": [{"tags": ["x_refsource_MISC", "x_transferred"], "url": "https://xenbits.xenproject.org/xsa/advisory-368.txt"}, {"name": "GLSA-202107-30", "tags": ["vendor-advisory", "x_refsource_GENTOO", "x_transferred"], "url": "https://security.gentoo.org/glsa/202107-30"}]}]}, "cveMetadata": {"assignerOrgId": "23aa2041-22e1-471f-9209-9b7396fa234f", "assignerShortName": "XEN", "cveId": "CVE-2021-28687", "datePublished": "2021-06-11T14:54:14", "dateReserved": "2021-03-18T00:00:00", "dateUpdated": "2024-08-03T21:47:33.121Z", "state": "PUBLISHED"}, "dataType": "CVE_RECORD", "dataVersion": "5.1"}

{}

{"configurations": [{"nodes": [{"cpeMatch": [{"criteria": "cpe:2.3:o:xen:xen:*:*:*:*:*:*:*:*", "matchCriteriaId": "3E9CE2ED-57BB-4DE3-85AF-3434645E0B96", "versionEndIncluding": "4.15.0", "versionStartIncluding": "4.12", "vulnerable": true}, {"criteria": "cpe:2.3:o:xen:xen:4.15.0:rc1:*:*:*:*:*:*", "matchCriteriaId": "68E7691E-21CB-46E3-823B-4262C9E5C33E", "vulnerable": true}], "negate": false, "operator": "OR"}]}], "descriptions": [{"lang": "en", "value": "HVM soft-reset crashes toolstack libxl requires all data structures passed across its public interface to be initialized before use and disposed of afterwards by calling a specific set of functions. Many internal data structures also require this initialize / dispose discipline, but not all of them. When the \"soft reset\" feature was implemented, the libxl__domain_suspend_state structure didn't require any initialization or disposal. At some point later, an initialization function was introduced for the structure; but the \"soft reset\" path wasn't refactored to call the initialization function. When a guest nwo initiates a \"soft reboot\", uninitialized data structure leads to an assert() when later code finds the structure in an unexpected state. The effect of this is to crash the process monitoring the guest. How this affects the system depends on the structure of the toolstack. For xl, this will have no security-relevant effect: every VM has its own independent monitoring process, which contains no state. The domain in question will hang in a crashed state, but can be destroyed by `xl destroy` just like any other non-cooperating domain. For daemon-based toolstacks linked against libxl, such as libvirt, this will crash the toolstack, losing the state of any in-progress operations (localized DoS), and preventing further administrator operations unless the daemon is configured to restart automatically (system-wide DoS). If crashes \"leak\" resources, then repeated crashes could use up resources, also causing a system-wide DoS."}, {"lang": "es", "value": "HVM soft-reset bloquea toolstack libxl requiere que todas las estructuras de datos pasadas a trav\u00e9s de su interfaz p\u00fablica sean inicializadas antes de usarlas y eliminadas despu\u00e9s llamando a un conjunto espec\u00edfico de funciones. Muchas estructuras de datos internas tambi\u00e9n requieren esta disciplina de inicializaci\u00f3n y eliminaci\u00f3n, pero no todas. Cuando se implement\u00f3 la funcionalidad \"soft reset\", la estructura libxl__domain_suspend_state no requer\u00eda ninguna inicializaci\u00f3n o eliminaci\u00f3n. En alg\u00fan momento posterior, se introdujo una funci\u00f3n de inicializaci\u00f3n para la estructura; pero la ruta \"soft reset\" no se refactoriz\u00f3 para llamar a la funci\u00f3n de inicializaci\u00f3n. Cuando un nwo invitado inicia un \"soft reset\", la estructura de datos no inicializada conlleva a una funci\u00f3n assert() cuando el c\u00f3digo posterior encuentra la estructura en un estado inesperado. El efecto de esto es que se bloquea el proceso que monitoriza el hu\u00e9sped. C\u00f3mo afecta esto al sistema depende de la estructura de la pila de herramientas. Para xl, esto no tendr\u00e1 ning\u00fan efecto relevante para la seguridad: cada VM presenta su propio proceso de monitorizaci\u00f3n independiente, que no contiene ning\u00fan estado. El dominio en cuesti\u00f3n se colgar\u00e1 en un estado de colapso, pero puede ser destruido por \"xl destroy\" como cualquier otro dominio no cooperante. Para las pilas de herramientas basadas en daemon enlazadas con libxl, como libvirt, esto bloquear\u00e1 la pila de herramientas, perdiendo el estado de cualquier operaci\u00f3n en curso (DoS localizado), e impidiendo m\u00e1s operaciones del administrador a menos que el demonio est\u00e9 configurado para reiniciarse autom\u00e1ticamente (DoS en todo el sistema). Si los bloqueos \"leak\" recursos, entonces los bloqueos repetidos podr\u00edan usar recursos, causando tambi\u00e9n una DoS a nivel de sistema"}], "id": "CVE-2021-28687", "lastModified": "2024-11-21T06:00:08.673", "metrics": {"cvssMetricV2": [{"acInsufInfo": false, "baseSeverity": "MEDIUM", "cvssData": {"accessComplexity": "LOW", "accessVector": "LOCAL", "authentication": "NONE", "availabilityImpact": "COMPLETE", "baseScore": 4.9, "confidentialityImpact": "NONE", "integrityImpact": "NONE", "vectorString": "AV:L/AC:L/Au:N/C:N/I:N/A:C", "version": "2.0"}, "exploitabilityScore": 3.9, "impactScore": 6.9, "obtainAllPrivilege": false, "obtainOtherPrivilege": false, "obtainUserPrivilege": false, "source": "nvd@nist.gov", "type": "Primary", "userInteractionRequired": false}], "cvssMetricV31": [{"cvssData": {"attackComplexity": "LOW", "attackVector": "LOCAL", "availabilityImpact": "HIGH", "baseScore": 5.5, "baseSeverity": "MEDIUM", "confidentialityImpact": "NONE", "integrityImpact": "NONE", "privilegesRequired": "LOW", "scope": "UNCHANGED", "userInteraction": "NONE", "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H", "version": "3.1"}, "exploitabilityScore": 1.8, "impactScore": 3.6, "source": "nvd@nist.gov", "type": "Primary"}]}, "published": "2021-06-11T15:15:11.153", "references": [{"source": "security@xen.org", "tags": ["Third Party Advisory"], "url": "https://security.gentoo.org/glsa/202107-30"}, {"source": "security@xen.org", "tags": ["Vendor Advisory"], "url": "https://xenbits.xenproject.org/xsa/advisory-368.txt"}, {"source": "af854a3a-2127-422b-91ae-364da2661108", "tags": ["Third Party Advisory"], "url": "https://security.gentoo.org/glsa/202107-30"}, {"source": "af854a3a-2127-422b-91ae-364da2661108", "tags": ["Vendor Advisory"], "url": "https://xenbits.xenproject.org/xsa/advisory-368.txt"}], "sourceIdentifier": "security@xen.org", "vulnStatus": "Modified", "weaknesses": [{"description": [{"lang": "en", "value": "CWE-909"}], "source": "nvd@nist.gov", "type": "Primary"}]}

{}