github - ghsa-f8g3-gxq4-xqv7

ghsa-f8g3-gxq4-xqv7

Vulnerability from github

Published

2022-05-24 19:05

Modified

2022-05-24 19:05

Details

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.

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2021-28687"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-909"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-06-11T15:15:00Z",
    "severity": "MODERATE"
  },
  "details": "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\u0027t require any initialization or disposal. At some point later, an initialization function was introduced for the structure; but the \"soft reset\" path wasn\u0027t 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.",
  "id": "GHSA-f8g3-gxq4-xqv7",
  "modified": "2022-05-24T19:05:06Z",
  "published": "2022-05-24T19:05:06Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-28687"
    },
    {
      "type": "WEB",
      "url": "https://security.gentoo.org/glsa/202107-30"
    },
    {
      "type": "WEB",
      "url": "https://xenbits.xenproject.org/xsa/advisory-368.txt"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

cve-2021-28687

Vulnerability from cvelistv5

Published

2021-06-11 14:54

Modified

2024-08-03 21:47

Severity ?

Summary

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.

References

▼	URL	Tags
	https://xenbits.xenproject.org/xsa/advisory-368.txt	x_refsource_MISC
	https://security.gentoo.org/glsa/202107-30	vendor-advisory, x_refsource_GENTOO

Impacted products

Vendor

Product

Version

▼

Xen

xen

Version: xen-unstable

	Xen	xen	Version: 4.12.x < unspecified Patch: next of 4.13.x
	Xen	xen	Version: 4.14.x

Show details on NVD website

JSON

To clipboard

{
  "containers": {
    "adp": [
      {
        "providerMetadata": {
          "dateUpdated": "2024-08-03T21:47:33.121Z",
          "orgId": "af854a3a-2127-422b-91ae-364da2661108",
          "shortName": "CVE"
        },
        "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"
          }
        ],
        "title": "CVE Program Container"
      }
    ],
    "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": "{\u0027credit_data\u0027: {\u0027description\u0027: {\u0027description_data\u0027: [{\u0027lang\u0027: \u0027eng\u0027, \u0027value\u0027: \u0027This issue was discovered by Olaf Hering.\u0027}]}}}"
        }
      ],
      "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\u0027t require any initialization or disposal. At some point later, an initialization function was introduced for the structure; but the \"soft reset\" path wasn\u0027t 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": "?\u003c",
                            "version_value": "4.12"
                          },
                          {
                            "version_affected": "\u003e=",
                            "version_value": "4.12.x"
                          },
                          {
                            "version_affected": "!\u003e",
                            "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\u0027t require any initialization or disposal. At some point later, an initialization function was introduced for the structure; but the \"soft reset\" path wasn\u0027t 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."
                }
              ]
            }
          }
        }
      }
    }
  },
  "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"
}

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.

Action not permitted