Cloudanix VulnDB

CVE-2026-98464

None

CVSS

—

EPSS

0.2%

Published

Oct 18, 2026

CISA due date

—

Cloudanix analysis

Next patch cycle SSVC: Track

A timing problem in how certain processors handle virtual machine timers could allow a guest to interfere with the host's internal memory handling during shutdown.

Exploitation
Local Privilege
Attacker needs
Low Privilege
Complexity
High
Impact
Full Compromise
Component
OS kernel
Class
Race Condition
Remediation
Patch
Effort
Medium
Patch risk
Low

What it actually does

Race condition during RISC-V KVM vCPU teardown allows hrtimer callback to execute after vCPU object has been freed, resulting in slab use-after-free when the callback invokes kvm_riscv_vcpu_set_interrupt.

Why it matters to the business

Virtual machines running on RISC-V hosts may trigger host kernel crashes or memory corruption during normal shutdown sequences, potentially affecting availability of virtualization workloads; low exploitability reduces immediate risk but still requires prompt kernel updates on affected systems.

How an attack unfolds

A guest uses SBI TIME to arm the timer then issues SBI legacy shutdown or SRST; a VMM that processes KVM_EXIT_SYSTEM_EVENT proceeds to destroy the VM, racing with the still-running hrtimer callback that clears next_set and later dereferences the freed vCPU structure.

How to fix it

Apply the upstream fix that unconditionally invokes hrtimer_cancel on initialized timers and synchronizes with any running callback before vCPU destruction; rebuild and deploy the corrected kernel on all RISC-V KVM hosts.

How to confirm the fix worked

Confirm the synchronization change is present in the kernel tree, then run repeated VM creation/teardown cycles under KASAN or with artificial delays after next_set clearing to verify absence of use-after-free reports.

Typical attack path

  1. Guest arms virtual timer via SBI TIME extension
  2. Guest requests VM shutdown via SBI legacy or SRST
  3. VMM observes system event exit and begins kvm_destroy_vm
  4. Teardown clears next_set without ensuring hrtimer callback has completed
  5. Callback runs after vCPU free, performing use-after-free write

How to detect it

Search kernel logs for KASAN slab-use-after-free reports referencing kvm_riscv_vcpu_set_interrupt, kvm_riscv_vcpu_hrtimer_expired, or paths through hrtimer_interrupt during VM teardown; correlate with guest-initiated SBI shutdown events.

What your security team should do

  • Prioritize kernel updates for all RISC-V hosts running KVM within the next patch cycle
  • Enable KASAN or similar debug kernels in staging environments to validate the fix
  • Monitor upstream stable branches for backports of the hrtimer synchronization change

The record

In the Linux kernel, the following vulnerability has been resolved: RISC-V: KVM: Synchronize hrtimer callback during teardown The non-Sstc hrtimer callback clears next_set before its final uses of the enclosing vCPU. If teardown observes next_set as false while the callback is still running, kvm_riscv_vcpu_timer_cancel() skips hrtimer_cancel() and kvm_destroy_vcpus() can free the vCPU before the callback enters kvm_riscv_vcpu_set_interrupt(). A guest can arm the timer with SBI TIME and request shutdown with SBI legacy shutdown or SRST. A VMM that honors KVM_EXIT_SYSTEM_EVENT and destroys the VM supplies the teardown side of the race; no post-launch host ioctl is needed to arm or request teardown. On upstream master 62cc90241548, generic KASAN reported: BUG: KASAN: slab-use-after-free in do_raw_spin_lock Write of size 4 at addr ff60000005e58898 kvm_riscv_vcpu_set_interrupt kvm_riscv_vcpu_hrtimer_expired __hrtimer_run_queues hrtimer_interrupt The object was allocated by KVM_CREATE_VCPU and freed concurrently by: kvm_destroy_vcpus kvm_arch_destroy_vm kvm_destroy_vm __fput For deterministic validation, I added mdelay(1000) immediately after the existing next_set = false assignment. This only widens the existing post-clear callback window. A no-delay trace build naturally reached the callback-after-teardown-start/before-deinit ordering in 12 of 200 runs, but 1,500 stock-kernel stress iterations did not produce a KASAN report, so natural reproduction is timing-sensitive. Always invoke hrtimer_cancel() for an initialized timer. Preserve the existing -EINVAL result when the timer is no longer set, but only after synchronizing with a running callback. With this patch, hrtimer_cancel() blocked for the full widened callback window before vCPU destruction. KASAN reported no error in 100 fixed-and-widened runs or 200 fix-only timing-sweep runs.

Affected packages

Ecosystem Package Introduced Fixed