Cloudanix VulnDB

CVE-2026-98465

None

CVSS

—

EPSS

0.2%

Published

Oct 18, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A timing flaw in certain Linux virtualization software on RISC-V hardware could let one virtual machine accidentally interfere with another's hardware interrupts until the system is updated.

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

What it actually does

Race condition in RISC-V KVM IMSIC handling allows a concurrent vCPU migration to recycle a VS-file's HGEI while an unsynchronized device ioctl holds a stale snapshot, enabling a GET/SET attribute operation to access another vCPU's interrupt file.

Why it matters to the business

Virtual machines running on affected RISC-V hosts may experience unexpected interrupt delivery, data leakage between guests, or kernel-level instability that disrupts hosted workloads and requires unplanned restarts.

How an attack unfolds

An attacker with the ability to issue KVM device ioctls and trigger vCPU migration on the same host issues an IMSIC attribute read/write at the precise moment a migration releases the VS-file; the ioctl then operates on the now-reassigned HGEI belonging to a different vCPU.

How to fix it

Apply the upstream kernel commit that acquires the target vCPU mutex for the duration of the IMSIC attribute operation; rebuild and deploy the updated kernel image on all RISC-V KVM hosts.

How to confirm the fix worked

Confirm the mutex acquisition (mutex_lock_killable) surrounds the entire kvm_riscv_aia_imsic_rw_attr path in the running kernel source or binary; re-test concurrent migration and attribute ioctl sequences for absence of cross-vCPU access.

Typical attack path

  1. Obtain capability to execute KVM_RUN and KVM device ioctls inside a guest or from the host.
  2. Trigger repeated vCPU migration while simultaneously performing IMSIC attribute GET/SET operations.
  3. Exploit the window where the stale physical CPU/HGEI tuple is used against the newly allocated interrupt file.

How to detect it

Review kernel logs for unexpected IMSIC or AIA warnings, guest interrupt mis-delivery events, or vCPU migration failures around the time of attribute operations; examine auditd or syscall traces for concurrent KVM_SET_DEVICE_ATTR and migration ioctls.

What your security team should do

  • Prioritize patching of RISC-V KVM hosts within standard change windows given low EPSS and absence from KEV.
  • Audit virtualization configurations to ensure least-privilege access to KVM device ioctls.
  • Monitor for future backports into distribution kernels and apply them promptly.

The record

In the Linux kernel, the following vulnerability has been resolved: RISC-V: KVM: Serialize IMSIC attributes with vCPU migration KVM device ioctls are not serialized against KVM_RUN. As a result, kvm_riscv_aia_imsic_rw_attr() can snapshot the physical CPU and HGEI of an IMSIC VS-file before a concurrent vCPU migration releases it. The HGEI can then be allocated to another vCPU before imsic_vsfile_rw() uses the stale tuple. A GET or SET attribute may consequently access the new owner's interrupt file. Serialize the entire IMSIC attribute operation with the target vCPU mutex. This prevents the VS-file from being migrated and recycled until the attribute access completes. Acquire the mutex killably so that the device ioctl remains interruptible while waiting for KVM_RUN to finish.

Affected packages

Ecosystem Package Introduced Fixed