{"id":"CVE-2026-80895","summary":"mshv: Order pt_vp_array publish against irqfd assertion path","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.","modified":"2026-09-06T03:47:08.311347506Z","published":"2026-09-04T17:11:10.880Z","database_specific":{"osv_generated_from":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/80xxx/CVE-2026-80895.json","cna_assigner":"Linux"},"references":[{"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"},{"type":"ADVISORY","url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/80xxx/CVE-2026-80895.json"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-80895"},{"type":"PACKAGE","url":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git"}],"affected":[{"ranges":[{"type":"GIT","repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","events":[{"introduced":"621191d709b14882270dfd8ea5d7d6cdfebe2c35"},{"fixed":"062aa5dcc49a9ad96726a80c2a0ab0a1233bc2b9"},{"fixed":"eba2bf5daa7933f94c53ebbbf0f567d4274716df"},{"fixed":"b098dc869219c15dc49bf9cf63fb5fc1481d3373"}]}],"database_specific":{"source":"https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-80895.json"}},{"package":{"name":"Kernel","ecosystem":"Linux"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"6.15.0"},{"fixed":"6.18.44"}]},{"type":"ECOSYSTEM","events":[{"introduced":"6.19.0"},{"fixed":"7.1.8"}]}],"database_specific":{"source":"https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-80895.json"}}],"schema_version":"1.9.0"}