GHSA-8532-XHGQ-93CJ
Vulnerability from github – Published: 2026-09-04 18:31 – Updated: 2026-09-04 18:31In the Linux kernel, the following vulnerability has been resolved:
mshv: Order pt_vp_array publish against irqfd assertion path
mshv_partition_ioctl_create_vp() initialises a VP struct (allocations, mutex_init, init_waitqueue_head, page mappings) and then publishes the pointer into partition->pt_vp_array. Several ISR paths read this array locklessly: the intercept ISR, the two scheduler ISRs, and mshv_try_assert_irq_fast() on the irqfd fast path.
Of these, only mshv_try_assert_irq_fast() can structurally race the publish. It runs from an eventfd waker without holding pt_mutex, and MSHV_IRQFD does not require the target lapic_apic_id (== vp_index) to refer to an existing VP at registration time. A user can therefore register an irqfd targeting a yet-to-be-created VP, then trigger mshv_try_assert_irq_fast() concurrently with MSHV_CREATE_VP for the same index. On weakly-ordered architectures the reader can observe a non-NULL pointer in pt_vp_array before the initialising stores to the VP struct become visible, leading to use of partially-initialised fields (e.g. vp_register_page).
The other ISR readers cannot reach this race: the hypervisor will not generate intercept or scheduler messages for a VP that has never been told to run, and the user can only call MSHV_RUN_VP on the VP fd returned by MSHV_CREATE_VP, which by construction is returned after the publish. Leave those readers as plain loads.
Use smp_store_release() in mshv_partition_ioctl_create_vp() to publish the pointer, and pair it with smp_load_acquire() in mshv_try_assert_irq_fast(). On x86 these compile to plain accesses under TSO; on ARM64 they emit one-instruction acquire/release barriers, acceptable on this fast path.
The destroy-side path (destroy_partition() clearing pt_vp_array[i] to NULL after kfree(vp)) has a separate ordering and lifetime concern that is out of scope here.
{
"affected": [],
"aliases": [
"CVE-2026-80895"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-09-04T18:17:57Z",
"severity": null
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmshv: Order pt_vp_array publish against irqfd assertion path\n\nmshv_partition_ioctl_create_vp() initialises a VP struct (allocations,\nmutex_init, init_waitqueue_head, page mappings) and then publishes the\npointer into partition-\u003ept_vp_array. Several ISR paths read this array\nlocklessly: the intercept ISR, the two scheduler ISRs, and\nmshv_try_assert_irq_fast() on the irqfd fast path.\n\nOf these, only mshv_try_assert_irq_fast() can structurally race the\npublish. It runs from an eventfd waker without holding pt_mutex, and\nMSHV_IRQFD does not require the target lapic_apic_id (== vp_index) to\nrefer to an existing VP at registration time. A user can therefore\nregister an irqfd targeting a yet-to-be-created VP, then trigger\nmshv_try_assert_irq_fast() concurrently with MSHV_CREATE_VP for the\nsame index. On weakly-ordered architectures the reader can observe a\nnon-NULL pointer in pt_vp_array before the initialising stores to the\nVP struct become visible, leading to use of partially-initialised\nfields (e.g. vp_register_page).\n\nThe other ISR readers cannot reach this race: the hypervisor will not\ngenerate intercept or scheduler messages for a VP that has never been\ntold to run, and the user can only call MSHV_RUN_VP on the VP fd\nreturned by MSHV_CREATE_VP, which by construction is returned after\nthe publish. Leave those readers as plain loads.\n\nUse smp_store_release() in mshv_partition_ioctl_create_vp() to publish\nthe pointer, and pair it with smp_load_acquire() in\nmshv_try_assert_irq_fast(). On x86 these compile to plain accesses\nunder TSO; on ARM64 they emit one-instruction acquire/release barriers,\nacceptable on this fast path.\n\nThe destroy-side path (destroy_partition() clearing pt_vp_array[i] to\nNULL after kfree(vp)) has a separate ordering and lifetime concern\nthat is out of scope here.",
"id": "GHSA-8532-xhgq-93cj",
"modified": "2026-09-04T18:31:33Z",
"published": "2026-09-04T18:31:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-80895"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/062aa5dcc49a9ad96726a80c2a0ab0a1233bc2b9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b098dc869219c15dc49bf9cf63fb5fc1481d3373"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/eba2bf5daa7933f94c53ebbbf0f567d4274716df"
}
],
"schema_version": "1.4.0",
"severity": []
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.