CVE-2024-26902

What it actually does

Incorrect integer shift (1 << idx) instead of BIT() macro when setting bits in unsigned long overflowed_ctrs inside the RISC-V perf PMU overflow handler leads to NULL pointer dereference and kernel panic on counter-width mask retrieval.

Why it matters to the business

RISC-V Linux systems become unstable when performance monitoring tools are used, causing unexpected reboots or crashes that interrupt workloads relying on perf or similar tracing utilities.

How an attack unfolds

A local user invokes a perf command such as 'perf record -e branches' on affected RISC-V hardware; the resulting PMU overflow triggers the buggy handler path that dereferences a NULL pointer derived from the malformed bit operation, producing a fatal kernel oops.

How to fix it

Apply the upstream fix commit 3ede8e94de6b834b48b0643385e66363e7a04be9 or later stable kernel releases that replace the shift expression with the BIT() macro in the RISC-V perf PMU code.

How to confirm the fix worked

Confirm the patch is present by inspecting the source of riscv_pmu_ctr_get_width_mask, rebuild and boot the kernel, then rerun the triggering perf command to verify absence of the oops and panic.

Typical attack path

1. Obtain local shell access on a vulnerable RISC-V Linux system
2. Execute a perf command that arms hardware branch or cycle counters
3. Trigger counter overflow to invoke pmu_sbi_ovf_handler
4. Reach riscv_pmu_ctr_get_width_mask with corrupted overflowed_ctrs mask
5. Kernel performs NULL dereference and panics

How to detect it

Search kernel logs and dmesg for strings containing riscv_pmu_ctr_get_width_mask, pmu_sbi_ovf_handler, Unable to handle kernel NULL pointer dereference, and the exact badaddr or epc values shown in the advisory; also inspect crash dumps for the perf process context.

• riscv_pmu_ctr_get_width_mask+0x8/0x62
• pmu_sbi_ovf_handler+0x2e0/0x34e
• Unable to handle kernel NULL pointer dereference at virtual address 0000000000000098
• epc : ffffffff80aecd98
• perf record -e branches

What your security team should do

• Prioritize kernel updates on all RISC-V production systems within the next maintenance window
• Restrict unprivileged use of perf via sysctl or capabilities until patched
• Monitor kernel logs for riscv_pmu_ctr_get_width_mask and pmu_sbi_ovf_handler symbols in oops traces
• Test the fixed kernel on representative Sophgo and other RISC-V hardware before broad rollout