Live › vulnerability › CVE-2026-98464
Go to dashboardIn the RISC-V KVM timer code, a timer callback can run after the guest vCPU has been freed during VM shutdown, causing a use-after-free in the kernel. A guest that arms the SBI timer and requests shutdown can trigger the race when the VMM destroys the VM, and the sources do not state a confirmed attacker outcome beyond the memory corruption.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-23 21:57 UTC. All times on this page are UTC.
Hosts that run RISC-V KVM guests on the Linux kernel, where a guest can arm the SBI timer and request shutdown while the VMM destroys the VM. Hosts without RISC-V KVM are not affected by this flaw. The sources do not say which kernel versions are affected beyond upstream master at the time of testing.
No product ranges from the sources yet.
CONFIG_KVM on a riscv64 host).uname -r; the sources do not name a fixed version.Each row is the first time that source carried this signal. The analyst’s rows are its own findings.
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.
This page as .md · .json · in your agent: get_signal("CVE-2026-98464")
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.