Linux Kernel EUVD-2026-103704

Requires a RISC-V host running KVM with the non-Sstc timer path (hardware lacking the Sstc extension, so the kernel emulates the timer via hrtimer). The attacker must be able to run a guest VM and, inside it, arm the vCPU timer via SBI TIME and then request shutdown via SBI legacy shutdown or SRST. The teardown side of the race is supplied by a VMM that honors KVM_EXIT_SYSTEM_EVENT and destroys the VM; no post-launch host ioctl is needed. Limiting factors that reduce realistic risk: it is a timing-sensitive race (natural reproduction reached the vulnerable ordering in only 12 of 200 trace-build runs and 0 of 1,500 stock-kernel stress runs without an injected delay), it is confined to the RISC-V architecture and the non-Sstc configuration, and it requires guest-execution capability rather than any network access despite the supplied PR:N.

Signals conflict sharply here. The input CVSS base score is 9.3 (CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H), driven mainly by the scope change (guest-to-host) and full H/H/H impact, and the vuln.today decision label is act_now. Against that, EPSS is only 0.17% (6th percentile), there is no CISA KEV listing, and no public exploit identified at time of analysis - the only references are the six upstream git.kernel.org fix commits, not exploit code. The description itself undercuts the AC:L/PR:N metrics: this is a timing-sensitive use-after-free race, not a deterministic remote bug. The author reports it took an injected mdelay(1000) to reproduce reliably; a no-delay trace build reached the vulnerable ordering in only 12 of 200 runs, and 1,500 stock-kernel stress iterations produced no KASAN report at all. Exploitation also requires the attacker to control a guest VM on a RISC-V KVM host using the non-Sstc timer path, plus a VMM that honors KVM_EXIT_SYSTEM_EVENT and destroys the VM - so despite PR:N in the supplied vector, this is not a classic unauthenticated network flaw. Conflict to flag explicitly: the act_now label and 9.3 CVSS point to high urgency, but low EPSS, absent KEV, no public exploit, a timing-sensitive local race, and a niche RISC-V-only code path all indicate low real-world widespread-exploitation risk. For the small population running RISC-V KVM hosts with untrusted guests this is a genuine host-memory-corruption priority; for everyone else it is a high-CVSS issue with limited practical exposure. Note also the supplied CVSS vector's AV:L/AC:L/PR:N is questionable: a guest-triggered race should carry higher attack complexity and some privilege - verify against vendor/upstream scoring.

A threat actor who controls a guest VM on a RISC-V KVM host (using the non-Sstc timer emulation path) arms the vCPU timer via SBI TIME and then requests shutdown through SBI legacy shutdown or SRST; a VMM that honors KVM_EXIT_SYSTEM_EVENT destroys the VM while the hrtimer callback is still executing. Because teardown can observe next_set as false and skip hrtimer_cancel(), kvm_destroy_vcpus() frees the vCPU before the callback writes into it, yielding a slab use-after-free write in host kernel memory (confirmed by KASAN) that can crash or corrupt the host. No public exploit code exists - only upstream fix commits - and success is timing-sensitive, so the window is narrow without artificial delay.