CVE-2026-80895: mshv: Order pt_vp_array publish against irqfd assertion path
In the Linux kernel, the following vulnerability has been resolved:
mshv: Order ptvparray publish against irqfd assertion path
mshvpartitionioctlcreatevp() initialises a VP struct (allocations, mutexinit, initwaitqueuehead, page mappings) and then publishes the pointer into partition->ptvparray. Several ISR paths read this array locklessly: the intercept ISR, the two scheduler ISRs, and mshvtryassertirqfast() on the irqfd fast path.
Of these, only mshvtryassertirqfast() can structurally race the publish. It runs from an eventfd waker without holding ptmutex, and MSHVIRQFD does not require the target lapicapicid (== vpindex) 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 mshvtryassertirqfast() concurrently with MSHVCREATEVP for the same index. On weakly-ordered architectures the reader can observe a non-NULL pointer in ptvparray before the initialising stores to the VP struct become visible, leading to use of partially-initialised fields (e.g. vpregisterpage).
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 MSHVRUNVP on the VP fd returned by MSHVCREATEVP, which by construction is returned after the publish. Leave those readers as plain loads.
Use smpstorerelease() in mshvpartitionioctlcreatevp() to publish the pointer, and pair it with smploadacquire() in mshvtryassertirqfast(). 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 (destroypartition() clearing ptvparray[i] to NULL after kfree(vp)) has a separate ordering and lifetime concern that is out of scope here.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
In mshv_partition_ioctl_create_vp(), publish the VP struct pointer to partition->pt_vp_array using smp_store_release() so that initialisation stores complete before other code can observe the published non-NULL pointer.
mshv_partition_ioctl_create_vp() Memory ordering for publication of pt_vp_array = Use smp_store_release() - Configuration
In mshv_try_assert_irq_fast() on the irqfd fast path, load pt_vp_array using smp_load_acquire() paired with the smp_store_release() publisher to prevent the reader from observing a partially-initialised VP struct.
mshv_try_assert_irq_fast() (irqfd fast path reader) Memory ordering for reading from pt_vp_array = Use smp_load_acquire()
Event History
Frequently Asked Questions
Who can trigger the race condition?
A user able to register an MSHV irqfd and create a VP can target an irqfd at a VP index that does not yet exist, then trigger the irqfd concurrently with creation of that VP.
Are all lockless ISR readers of pt_vp_array affected?
No. The structurally reachable race is limited to mshv_try_assert_irq_fast() on the irqfd fast path; the intercept and scheduler ISR paths cannot reach this race because the hypervisor will not generate their relevant events before VP creation completes.
What is the impact of a successful race?
On weakly ordered architectures, the irqfd fast-path reader can observe a non-NULL VP pointer before initialization stores are visible. This can cause use of partially initialized VP fields, including vp_register_page.