In the Linux kernel, the following vulnerability has been resolved: RISC-V: KVM: Synchronize hrtimer callback during…
Linux · Linux
The Linux kernel's RISC-V KVM timer code has a race in vCPU teardown: the non-Sstc hrtimer callback can still be running after teardown has decided no cancellation is needed, so the vCPU can be freed while the callback is still touching it. An attacker who can run a guest on the affected host can arm the timer through SBI TIME and request shutdown through SBI legacy shutdown or SRST, with a VMM that destroys the VM on the resulting system event supplying the teardown side, and no post-launch host ioctl is needed.
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.
- Exploited
- Not confirmed
- Reports
- 0
- Tactics
- 0/15
Exploitation timelineDated milestones for a CVE: when it was disclosed, when exploit code became public, when exploitation was confirmed, and when threat reports named it.
Disclosed on 18 Oct 2026. No public exploit code or confirmed exploitation is recorded.
MITRE ATT&CKA public catalogue of the techniques attackers use, maintained by MITRE. Patchfirst uses it to describe what attackers do with a vulnerability. techniques
No techniques linkedNo ATT&CK techniques are linked to this CVE yet. MITRE CTID has not mapped it, and no report passage in the corpus ties it to a technique.
What security researchers reported
Not named in any threat report yetAlso mentioned in 4 community threat pulses (AlienVault OTX)
Weaker evidencePulses are indicator collections that anyone can publish. A mention is not confirmation of exploitation.
- Known_Cve | Oct 27, 2026 | Part 1/326 Oct 2026
- Known_Cve | Oct 24, 2026 | Part 1/323 Oct 2026
- Known_Cve | Oct 23, 2026 | Part 2/322 Oct 2026
- Known_Cve | Oct 22, 2026 | Part 3/421 Oct 2026