ghsa-7555-3222-qmcm
Vulnerability from github
Published
2024-09-27 15:30
Modified
2024-10-03 15:30
Details

In the Linux kernel, the following vulnerability has been resolved:

x86/hyperv: fix kexec crash due to VP assist page corruption

commit 9636be85cc5b ("x86/hyperv: Fix hyperv_pcpu_input_arg handling when CPUs go online/offline") introduces a new cpuhp state for hyperv initialization.

cpuhp_setup_state() returns the state number if state is CPUHP_AP_ONLINE_DYN or CPUHP_BP_PREPARE_DYN and 0 for all other states. For the hyperv case, since a new cpuhp state was introduced it would return 0. However, in hv_machine_shutdown(), the cpuhp_remove_state() call is conditioned upon "hyperv_init_cpuhp > 0". This will never be true and so hv_cpu_die() won't be called on all CPUs. This means the VP assist page won't be reset. When the kexec kernel tries to setup the VP assist page again, the hypervisor corrupts the memory region of the old VP assist page causing a panic in case the kexec kernel is using that memory elsewhere. This was originally fixed in commit dfe94d4086e4 ("x86/hyperv: Fix kexec panic/hang issues").

Get rid of hyperv_init_cpuhp entirely since we are no longer using a dynamic cpuhp state and use CPUHP_AP_HYPERV_ONLINE directly with cpuhp_remove_state().

Show details on source website


{
  "affected": [],
  "aliases": [
    "CVE-2024-46864"
  ],
  "database_specific": {
    "cwe_ids": [],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-09-27T13:15:17Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nx86/hyperv: fix kexec crash due to VP assist page corruption\n\ncommit 9636be85cc5b (\"x86/hyperv: Fix hyperv_pcpu_input_arg handling when\nCPUs go online/offline\") introduces a new cpuhp state for hyperv\ninitialization.\n\ncpuhp_setup_state() returns the state number if state is\nCPUHP_AP_ONLINE_DYN or CPUHP_BP_PREPARE_DYN and 0 for all other states.\nFor the hyperv case, since a new cpuhp state was introduced it would\nreturn 0. However, in hv_machine_shutdown(), the cpuhp_remove_state() call\nis conditioned upon \"hyperv_init_cpuhp \u003e 0\". This will never be true and\nso hv_cpu_die() won\u0027t be called on all CPUs. This means the VP assist page\nwon\u0027t be reset. When the kexec kernel tries to setup the VP assist page\nagain, the hypervisor corrupts the memory region of the old VP assist page\ncausing a panic in case the kexec kernel is using that memory elsewhere.\nThis was originally fixed in commit dfe94d4086e4 (\"x86/hyperv: Fix kexec\npanic/hang issues\").\n\nGet rid of hyperv_init_cpuhp entirely since we are no longer using a\ndynamic cpuhp state and use CPUHP_AP_HYPERV_ONLINE directly with\ncpuhp_remove_state().",
  "id": "GHSA-7555-3222-qmcm",
  "modified": "2024-10-03T15:30:50Z",
  "published": "2024-09-27T15:30:34Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46864"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/2ae1beb3ab4f28868cc5d1541d05e1fbee3ad825"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/b9af6418279c4cf73ca073f8ea024992b38be8ab"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/d6f018a3b49d0a94ddbd0e479c2af6b19724e434"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

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.