CVE-2026-98464

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.