Look up another CVE · open CVE-2026-89513 in the interactive tracker
CVE-2026-89513
RISC-V: KVM: Fix PMU event info array size overflow
Published 2026-09-11 (37 days ago) by the Linux kernel CNA. Subsystem arch/riscv. Debian urgency: unimportant.
What to do, per Debian release
Debian's own status for CVE-2026-89513 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | not affected | 6.1.190-1 | Nothing to do. bookworm never shipped the vulnerable code. |
| Debian 13trixie | not affected | 6.12.113-1 | Nothing to do. trixie never shipped the vulnerable code. |
| Debian 14forky | fixed | 7.2.6-1 | Update the kernel and reboot. Fixed in 7.2.6-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.2.6-1 | Update the kernel and reboot. Fixed in 7.2.6-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
SBI PMU EVENT_GET_INFO stores guest-controlled num_events * sizeof(*einfo) in a 32-bit integer. On RV64, num_events = 0x10000001 makes 0x100000010 truncate to 16. KVM then allocates one entry but loops over the original num_events, causing out-of-bounds reads and writes. A nested guest triggered: BUG: KASAN: slab-out-of-bounds in kvm_riscv_vcpu_pmu_event_info+0xa4/0x142 Read of size 4 at addr ff600000074d46b0 by task init/1 Call Trace: [<ffffffff8006471c>] kvm_riscv_vcpu_pmu_event_info+0xa4/0x142 [<ffffffff800690c0>] kvm_sbi_ext_pmu_handler+0xca/0x268 [<ffffffff8006779e>] kvm_riscv_vcpu_sbi_ecall+0xec/0x1e6 [<ffffffff8006008c>] kvm_riscv_vcpu_exit+0x48c/0x540 [<ffffffff8005ea0a>] kvm_arch_vcpu_ioctl_run+0x37e/0xc80 Allocated by task 1: __kmalloc_noprof+0x19e/0x4b0 kvm_riscv_vcpu_pmu_event_info+0x72/0x142 kvm_sbi_ext_pmu_handler+0xca/0x268 kvm_riscv_vcpu_sbi_ecall+0xec/0x1e6 kvm_riscv_vcpu_exit+0x48c/0x540 kvm_arch_vcpu_ioctl_run+0x37e/0xc80 The buggy address is located 0 bytes to the right of allocated 16-byte region [ff600000074d46a0, ff600000074d46b0) Store the shared-memory size in size_t and reject multiplication overflow. Allocate the guest-driven array with GFP_KERNEL_ACCOUNT so it is charged to kmemcg, and use __GFP_NOWARN to suppress allocation failure warnings. Use kvcalloc() to allow vmalloc fallback and an unsigned long loop index to match num_events.
Where it lives
The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.
arch/riscv/kvm/vcpu_pmu.c
- What this is
- KERNEL VIRTUAL MACHINE FOR RISC-V (KVM/riscv)MAINTAINERS section matched on arch/riscv/kvm/ · kvm@vger.kernel.org · Maintained
- Kernel module
- kvm
Check it on the machine
grep -wE 'CONFIG_KVM|CONFIG_RISCV_PMU_SBI' /boot/config-$(uname -r)Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.
lsmod | grep -w kvmPrints a line if that module is loaded right now, and nothing if it is not. One that is not loaded can still be loaded later by anything that needs it.
Show whether Debian builds this, per release
Debian builds this, but not on every flavour. At least one release below builds the code on some of its kernel flavours and not on others, so the answer depends on the architecture and flavour installed. The build rule could not be established for 1 release, so nothing is claimed about those.
- bookworm?
- trixieMnot built on amd64/amd64, amd64/cloud-amd64, amd64/rt/amd64, arm64/arm64, arm64/arm64-16k, arm64/cloud-arm64, arm64/rt/arm64, armel/rpi, armhf/armmp, armhf/armmp-lpae, armhf/rt/armmp, ppc64el/powerpc64le, ppc64el/powerpc64le-64k, s390x/s390x
- forky, sidMnot built on amd64/amd64, amd64/cloud-amd64, amd64/rt-amd64, arm64/arm64, arm64/arm64-16k, arm64/cloud-arm64, arm64/rt-arm64, armhf/armmp, armhf/armmp-lpae, loong64/loong64, ppc64el/powerpc64le, ppc64el/powerpc64le-64k, s390x/s390x
- ?
- not established - no Makefile entry for the affected file
- M
- a module where it is built at all; some flavours do not build it
Where a release above reads "not established", no build rule for the affected file was found in that release's kernel tree. That is a gap in this lookup, not a finding that the code is absent.
- Build switches
- CONFIG_KVM, CONFIG_RISCV_PMU_SBI
- Reads as
- all on means the file is compiled; any one off means it is not.
From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages
Signals
- Published
- 2026-09-11 (37 days ago)source
- CVSS
- 8.8 high
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:Hsource recompute it - Attack vector
- local (AV:L)source
- EPSS
- 0.17%, higher than 6.3% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- unimportantsource
- Subsystem
- arch/riscv
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 6.18 | 6.18.57 | ddbd71a37809 |
| 6.18 | 7.2.4 | 82088f88c96b |
| 6.18 | 7.3 | 735bc20c2418 |
Why the CNA scored it this way
Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source
- AV:LAttack vector, local
- The overflow is reached when a RISC-V KVM guest issues an SBI ECALL (EXC_SUPERVISOR_SYSCALL) for SBI_EXT_PMU_EVENT_GET_INFO, handled on the host KVM_RUN path via kvm_riscv_vcpu_exit, kvm_riscv_vcpu_sbi_ecall, kvm_sbi_ext_pmu_handler, and kvm_riscv_vcpu_pmu_event_info; this is a local guest hypercall path with no network or physical exposure.
- AC:LAttack complexity, low
- A guest that sets flags=0, a 16-byte-aligned shared-memory GPA, and num_events=0x10000001 on RV64 makes num_events*sizeof(*einfo) truncate from 0x100000010 to 16, so kzalloc gets one entry while the loop uses the original count; the attacker controls every parameter and needs no race or uncontrollable host layout.
- PR:LPrivileges required, low
- Issuing the SBI ECALL requires VS-mode in a KVM guest (tenant kernel or custom image) or a host kvm-group user running QEMU, not host init-namespace root; kvm_sbi_ext_pmu_handler has no capability check, and SBI PMU is enabled by default once kvm_riscv_vcpu_pmu_init succeeds.
- UI:NUser interaction, none
- The attacker guest issues SBI_EXT_PMU_EVENT_GET_INFO itself during KVM_RUN; no separate victim action such as attaching a device, mounting a filesystem, or confirming a prompt is required.
- S:CScope, changed
- The slab out-of-bounds access runs in the host kernel while handling a guest SBI call, crossing the KVM guest-to-hypervisor boundary so host heap corruption can compromise the hypervisor and co-located VMs, which CNA guidance rates Changed for KVM guest-to-host escape.
- C:HConfidentiality impact, high
- After the truncated 16-byte allocation, the loop reads event_idx and event_data from adjacent host slab for 0x10000001 entries; that unbounded host-heap out-of-bounds read, together with the following heap corruption, can be leveraged for kernel memory disclosure.
- I:HIntegrity impact, high
- The same loop writes einfo[i].output (0 or 1) past the 16-byte object at a 16-byte stride for about 2^28 iterations, an unbounded host-slab out-of-bounds write that smashes neighboring objects and heap metadata and is scored High per CNA out-of-bounds-write guidance.
- A:HAvailability impact, high
- KASAN reported a host slab-out-of-bounds in kvm_riscv_vcpu_pmu_event_info, and walking billions of bytes past a 16-byte allocation reliably oopses or panics the host kernel, denying service to the hypervisor and every co-located VM.