CVE-2026-89513

What it actually does

A guest-controlled integer overflow in RISC-V KVM's SBI PMU EVENT_GET_INFO path multiplies num_events by sizeof(*einfo) into a 32-bit size. On RV64 a large num_events wraps the product (e.g. to 16 bytes), so KVM allocates a tiny slab object then iterates the original count, producing kernel slab out-of-bounds reads and writes in the hypervisor (changed scope from guest to host).

Why it matters to the business

A malicious or compromised RISC-V virtual machine—including a nested guest—can crash the host or corrupt hypervisor memory, taking down or exposing every workload on that machine. Impact is host-wide confidentiality, integrity, and availability, but the issue is RISC-V KVM-specific, not in CISA KEV, has no known exploits (maturity None), and a very low, flat EPSS (~0.00165 over 30 days). Treat as urgent on RISC-V virtualization hosts; elsewhere the practical mass-exploitation risk remains limited 32 days after publication.

How an attack unfolds

An attacker who already runs code in a RISC-V KVM guest (or nested guest) issues an SBI PMU EVENT_GET_INFO ecall with a crafted num_events so the 32-bit size computation overflows and KVM allocates far less memory than the following loop uses. Out-of-bounds reads and writes then hit adjacent kernel slab objects in kvm_riscv_vcpu_pmu_event_info. Heap corruption can panic the host or be turned into guest-to-host privilege escalation; no named threat actors or ransomware campaigns are associated with this flaw.

How to fix it

Install a Linux kernel build that includes the RISC-V KVM PMU EVENT_GET_INFO fix: shared-memory size stored in size_t with multiplication-overflow rejection, allocation via kvcalloc() with GFP_KERNEL_ACCOUNT and __GFP_NOWARN, and an unsigned long loop index matching num_events. Use your distro or vendor kernel package; no per-product fixed versions were supplied with this record. Reboot onto the patched kernel. Until then, do not run untrusted or nested guests on RISC-V KVM hosts and restrict guest access to SBI PMU where operations allow.

How to confirm the fix worked

Confirm the running kernel changelog or package notes the RISC-V KVM PMU event-info array size overflow fix, and that kvm_riscv_vcpu_pmu_event_info no longer stores num_events * sizeof(*einfo) in a 32-bit integer. After install, reboot and verify uname -r matches the patched build. On source trees, check for size_t sizing, overflow rejection, kvcalloc, GFP_KERNEL_ACCOUNT, and an unsigned long loop index. Do not probe live hosts with oversized num_events.

Typical attack path

1. Obtain code execution in a RISC-V KVM guest or nested guest that can issue SBI ecalls
2. Call SBI PMU EVENT_GET_INFO with a guest-controlled num_events that overflows the 32-bit size calculation
3. Cause KVM to allocate an undersized event-info buffer then loop over the original num_events
4. Trigger slab out-of-bounds reads/writes in the host KVM PMU handler
5. Corrupt neighboring kernel heap to deny service on the host or escalate from guest to hypervisor

How to detect it

This is a host-kernel memory-corruption bug; evidence of attempted or successful use appears in host kernel logs, kdump/vmcore, and KASAN/KUP reports—not in guest userland. Search dmesg, journalctl -k, /var/log/kern.log, and crash dumps for slab-out-of-bounds or Oops in kvm_riscv_vcpu_pmu_event_info, reached via kvm_sbi_ext_pmu_handler and kvm_riscv_vcpu_sbi_ecall during kvm_arch_vcpu_ioctl_run. Correlate with RISC-V KVM vCPU threads and nested-guest activity. Allocation traces showing __kmalloc followed immediately by that PMU handler with a tiny (e.g. 16-byte) object are consistent with the overflow. No public exploit tooling or named actor TTPs are documented; absence of these logs does not prove the host was never targeted.

• BUG: KASAN: slab-out-of-bounds in kvm_riscv_vcpu_pmu_event_info
• kvm_riscv_vcpu_pmu_event_info
• kvm_sbi_ext_pmu_handler
• kvm_riscv_vcpu_sbi_ecall
• kvm_riscv_vcpu_exit
• kvm_arch_vcpu_ioctl_run
• KASAN: slab-out-of-bounds

What your security team should do

• Inventory RISC-V hosts running KVM and patch/reboot them first; this CVE does not apply to non-RISC-V kernels
• Block or tightly control untrusted and nested guests on unpatched RISC-V KVM until the fix is live
• Disable or limit guest SBI PMU if the workload does not require it
• Hunt kernel logs and crash dumps for KASAN/OOPS in the KVM PMU SBI path (see detection_guidance)
• Track distro kernel advisories for the exact package version; EPSS is low and KEV is false, but host-escape class bugs should still be closed on affected virtualization nodes