<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title>Most recent entries from all</title>
    <link>https://db.gcve.eu</link>
    <description>Contains only the most 10 recent entries.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Mon, 02 Nov 2026 22:29:30 +0000</lastBuildDate>
    <item>
      <title>CVE-2026-98464 — RISC-V: KVM: Synchronize hrtimer callback during teardown</title>
      <link>https://db.gcve.eu/vuln/cve-2026-98464</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Linux&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;RISC-V: KVM: Synchronize hrtimer callback during teardown&lt;/p&gt;
&lt;p&gt;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().&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;On upstream master 62cc90241548, generic KASAN reported:&lt;/p&gt;
&lt;p&gt;BUG: KASAN: slab-use-after-free in do_raw_spin_lock
  Write of size 4 at addr ff60000005e58898&lt;/p&gt;
&lt;p&gt;kvm_riscv_vcpu_set_interrupt
  kvm_riscv_vcpu_hrtimer_expired
  __hrtimer_run_queues
  hrtimer_interrupt&lt;/p&gt;
&lt;p&gt;The object was allocated by KVM_CREATE_VCPU and freed concurrently by:&lt;/p&gt;
&lt;p&gt;kvm_destroy_vcpus
  kvm_arch_destroy_vm
  kvm_destroy_vm
  __fput&lt;/p&gt;
&lt;p&gt;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 reproducti…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Linux&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;RISC-V: KVM: Synchronize hrtimer callback during teardown&lt;/p&gt;
&lt;p&gt;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().&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;On upstream master 62cc90241548, generic KASAN reported:&lt;/p&gt;
&lt;p&gt;BUG: KASAN: slab-use-after-free in do_raw_spin_lock
  Write of size 4 at addr ff60000005e58898&lt;/p&gt;
&lt;p&gt;kvm_riscv_vcpu_set_interrupt
  kvm_riscv_vcpu_hrtimer_expired
  __hrtimer_run_queues
  hrtimer_interrupt&lt;/p&gt;
&lt;p&gt;The object was allocated by KVM_CREATE_VCPU and freed concurrently by:&lt;/p&gt;
&lt;p&gt;kvm_destroy_vcpus
  kvm_arch_destroy_vm
  kvm_destroy_vm
  __fput&lt;/p&gt;
&lt;p&gt;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 reproducti…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/cve-2026-98464</guid>
    </item>
  </channel>
</rss>
