Cloudanix VulnDB

CVE-2026-80895

None

CVSS

—

EPSS

0.2%

Published

Sep 4, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A timing flaw in Linux kernel code that manages virtual processors can let an attacker trigger crashes or unexpected behavior by racing the setup of a new processor against certain fast-path operations.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Moderate
Impact
Other
Component
OS kernel
Class
Race Condition
Remediation
Patch
Effort
Medium
Patch risk
Low

What it actually does

A missing memory ordering barrier allows a reader in the irqfd fast path to observe a partially-initialized VP structure in pt_vp_array, leading to access of uninitialized fields such as vp_register_page on weakly-ordered architectures.

Why it matters to the business

Systems using the mshv driver face risk of kernel instability, crashes, or potential privilege escalation in hypervisor contexts, which can disrupt virtual machine hosting and require urgent patching across Linux deployments.

How an attack unfolds

An attacker registers an irqfd targeting a non-existent VP index without requiring the lapic_apic_id to exist at registration, then concurrently invokes MSHV_CREATE_VP for the same index while triggering mshv_try_assert_irq_fast from an eventfd waker, allowing the lockless reader to dereference a pointer before initialization stores are visible.

How to fix it

Apply the upstream kernel fix that replaces the plain store of the VP pointer with smp_store_release in mshv_partition_ioctl_create_vp and pairs it with smp_load_acquire in mshv_try_assert_irq_fast; rebuild and deploy the updated kernel image.

How to confirm the fix worked

Inspect the mshv source for smp_store_release on the pt_vp_array publish and smp_load_acquire on the fast-path reader; confirm the race window is closed by reviewing the ordering of initialization versus publication.

Typical attack path

  1. Register an irqfd for a VP index that does not yet exist
  2. Concurrently issue MSHV_CREATE_VP for the target index
  3. Trigger the eventfd waker to invoke mshv_try_assert_irq_fast during VP initialization
  4. Observe non-NULL pointer with uninitialized fields on weakly-ordered architectures

How to detect it

Review kernel logs for oops or panic messages referencing mshv_try_assert_irq_fast, pt_vp_array, or uninitialized accesses to vp_register_page; monitor for unexpected concurrent MSHV_CREATE_VP and irqfd registration patterns in audit trails.

What your security team should do

  • Prioritize kernel updates containing the acquire/release barriers for any hosts running mshv
  • Audit workloads that register irqfds before VP creation for exposure to the race
  • Test updated kernels under concurrent irqfd and VP creation workloads before broad rollout

The record

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.

Affected packages

Ecosystem Package Introduced Fixed