CVE-2026-98464: RISC-V: KVM: Synchronize hrtimer callback during teardown
In the Linux kernel, the following vulnerability has been resolved:
RISC-V: KVM: Synchronize hrtimer callback during teardown
The non-Sstc hrtimer callback clears nextset before its final uses of the enclosing vCPU. If teardown observes nextset as false while the callback is still running, kvmriscvvcputimercancel() skips hrtimercancel() and kvmdestroyvcpus() can free the vCPU before the callback enters kvmriscvvcpusetinterrupt().
A guest can arm the timer with SBI TIME and request shutdown with SBI legacy shutdown or SRST. A VMM that honors KVMEXITSYSTEMEVENT 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 dorawspinlock Write of size 4 at addr ff60000005e58898
kvmriscvvcpusetinterrupt kvmriscvvcpuhrtimerexpired hrtimerrunqueues hrtimerinterrupt
The object was allocated by KVMCREATEVCPU and freed concurrently by:
kvmdestroyvcpus kvmarchdestroyvm kvmdestroyvm fput
For deterministic validation, I added mdelay(1000) immediately after the existing nextset = 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 hrtimercancel() 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, hrtimercancel() 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 Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Compensating control
During RISC-V KVM vCPU teardown, synchronize with a running non-Sstc hrtimer callback by always invoking hrtimer_cancel() for an initialized timer before freeing the vCPU.
Event History
Frequently Asked Questions
Which systems are exposed to this race?
The issue affects RISC-V KVM using the non-Sstc timer path. Exposure requires a VMM that honors KVM_EXIT_SYSTEM_EVENT and destroys the VM after a guest shutdown request.
What must a guest do to trigger the vulnerable sequence?
A guest can arm its timer using SBI TIME and then request shutdown using SBI legacy shutdown or SRST. No post-launch host ioctl is needed to arm the timer or request teardown.
What is the likely impact if the race occurs?
The vCPU can be freed while the hrtimer callback is still executing and later accesses it, causing a slab use-after-free. The reported KASAN failure occurred in kvm_riscv_vcpu_set_interrupt during the hrtimer callback.
How can the condition be detected during testing?
KASAN can report a slab-use-after-free involving kvm_riscv_vcpu_set_interrupt, kvm_riscv_vcpu_hrtimer_expired, and hrtimer interrupt handling, with the vCPU freed through VM destruction. The report describes deterministic validation by delaying execution immediately after next_set is cleared.