CVE-2026-97587: perf: RISC-V: store available counter mask as bitmap
In the Linux kernel, the following vulnerability has been resolved:
perf: RISC-V: store available counter mask as bitmap
The available-counter mask was a single unsigned long, but iteration uses RISCVMAXCOUNTERS, which is 64. On RV32 that reads past the object. Filling with an unsigned-long bit at index 32 and above is also wrong.
Use DECLAREBITMAP and setbit/bitmap helpers. Walk each bitmap word into CFGMATCH when checking events, when allocating an index, and when stopping all counters. Set the counter base to i times BITSPERLONG. Share the CFGMATCH ecall through a small helper so the 32-bit argument split is not duplicated. On qemu-system-riscv32 the probe bitmap has bits above XLEN set, so the first word alone is not enough.
[pjw@kernel.org: updated to apply; fixed checkpatch.pl issues]
Affected Software
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
The issue affects the Linux kernel perf RISC-V implementation on 32-bit RISC-V (RV32). It occurs because the available-counter mask is stored in one unsigned long while the code iterates across up to 64 counters.
What conditions are needed to trigger the problem?
The affected perf code must process available hardware performance-counter bits at indexes 32 or higher on RV32. The description notes that qemu-system-riscv32 can report probe bitmap bits above the XLEN-sized first word, so checking only that word is insufficient.
What is the practical effect of the fix?
The fix stores the available-counter mask as a bitmap and uses bitmap helpers for event checks, counter-index allocation, and stopping counters. It also calculates counter bases per bitmap word, allowing counters above the first 32-bit word to be handled correctly on RV32.