CVE-2026-80895: mshv: Order pt_vp_array publish against irqfd assertion path

CVE-2026-80895: mshv: Order pt_vp_array publish against irqfd assertion path

[Greg Kroah-Hartman]

From: Greg Kroah-Hartman <gregkh@kernel.org>

Description
===========

In 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.

The Linux kernel CVE team has assigned CVE-2026-80895 to this issue.


Affected and fixed versions
===========================

	Issue introduced in 6.15 with commit 621191d709b14882270dfd8ea5d7d6cdfebe2c35 and fixed in 6.18.44 with commit 062aa5dcc49a9ad96726a80c2a0ab0a1233bc2b9
	Issue introduced in 6.15 with commit 621191d709b14882270dfd8ea5d7d6cdfebe2c35 and fixed in 7.1.8 with commit eba2bf5daa7933f94c53ebbbf0f567d4274716df
	Issue introduced in 6.15 with commit 621191d709b14882270dfd8ea5d7d6cdfebe2c35 and fixed in 7.2 with commit b098dc869219c15dc49bf9cf63fb5fc1481d3373

Please see https://www.kernel.org for a full list of currently supported
kernel versions by the kernel community.

Unaffected versions might change over time as fixes are backported to
older supported kernel versions.  The official CVE entry at
	https://cve.org/CVERecord/?id=CVE-2026-80895
will be updated if fixes are backported, please check that for the most
up to date information about this issue.


Affected files
==============

The file(s) affected by this issue are:
	drivers/hv/mshv_eventfd.c
	drivers/hv/mshv_root_main.c


Mitigation
==========

The Linux kernel CVE team recommends that you update to the latest
stable kernel version for this, and many other bugfixes.  Individual
changes are never tested alone, but rather are part of a larger kernel
release.  Cherry-picking individual commits is not recommended or
supported by the Linux kernel community at all.  If however, updating to
the latest release is impossible, the individual changes to resolve this
issue can be found at these commits:
	https://git.kernel.org/stable/c/062aa5dcc49a9ad96726a80c2a0ab0a1233bc2b9
	https://git.kernel.org/stable/c/eba2bf5daa7933f94c53ebbbf0f567d4274716df
	https://git.kernel.org/stable/c/b098dc869219c15dc49bf9cf63fb5fc1481d3373