CVE-2025-63913: OpenSBI 1.3 Denial of Service Vulnerability

CVE-2025-63913 Overview

CVE-2025-63913 is a denial-of-service vulnerability in OpenSBI 1.3, the reference implementation of the RISC-V Supervisor Binary Interface (SBI). Attackers can crash the firmware by sending a crafted request to SBI function #2 or the "Find and configure a matching counter" function of the SBI Performance Monitoring Unit (PMU) extension. The flaw is classified under CWE-400 (Uncontrolled Resource Consumption) and impacts the availability of RISC-V systems relying on OpenSBI for machine-mode services. A public proof-of-concept is available in the opensbi-pmu2-crash repository.

Critical Impact
A crafted SBI PMU request can crash OpenSBI 1.3, disrupting the supervisor-mode operating system running on the affected RISC-V hardware.

Affected Products

OpenSBI version 1.3
RISC-V platforms using OpenSBI 1.3 as their SBI implementation
Downstream firmware distributions bundling OpenSBI 1.3

Discovery Timeline

2026-07-27 - CVE-2025-63913 published to NVD
2026-07-28 - Last updated in NVD database

Technical Details for CVE-2025-63913

Vulnerability Analysis

OpenSBI provides runtime services to supervisor-mode software on RISC-V processors. The SBI PMU extension exposes counter management functions to the operating system through ecall interfaces. CVE-2025-63913 affects two entry points: SBI function #2 and the counter-matching routine of the PMU extension.

A crafted SBI request triggers uncontrolled resource consumption inside the firmware. Because OpenSBI executes in machine mode, a crash propagates upward and halts the supervisor operating system. The published PoC demonstrates that a locally executing unprivileged program can reach the vulnerable path through the standard SBI ecall interface.

Root Cause

The root cause is insufficient validation of parameters passed to the PMU counter configuration logic. The affected routines do not correctly bound-check or sanitize the counter-matching request, leading to a fault inside OpenSBI. [CWE-400] classifies this as an uncontrolled resource consumption weakness in the firmware trust boundary.

Attack Vector

The attack is delivered through a legitimate SBI ecall from supervisor mode. Any component able to issue SBI calls, including the guest kernel or a compromised driver, can supply the malformed arguments. No authentication is required at the SBI boundary because SBI is designed to be called by the operating system directly.

The vulnerability manifests when the crafted arguments are processed by the PMU extension handler. See the public PoC for technical reproduction details.

Detection Methods for CVE-2025-63913

Indicators of Compromise

Unexpected firmware halts or platform resets on RISC-V hardware running OpenSBI 1.3
Kernel logs showing SBI ecall failures followed by loss of machine-mode services
Repeated SBI PMU extension calls with malformed counter configuration parameters preceding a crash

Detection Strategies

Audit kernel dmesg output for SBI ecall errors targeting the PMU extension (extension ID 0x504D55)
Monitor for abnormal termination of the supervisor OS on affected RISC-V systems
Instrument OpenSBI builds with logging around sbi_pmu_ctr_cfg_match to record suspicious argument values

Monitoring Recommendations

Track availability metrics for RISC-V nodes and correlate outages with SBI activity logs
Enable serial console capture on RISC-V hardware to preserve firmware crash traces
Baseline expected PMU counter configuration patterns for workloads and alert on outliers

How to Mitigate CVE-2025-63913

Immediate Actions Required

Inventory all RISC-V systems and identify firmware images built with OpenSBI 1.3
Restrict which workloads can issue arbitrary SBI PMU calls in multi-tenant RISC-V environments
Apply upstream OpenSBI patches once released and rebuild platform firmware

Patch Information

No official patched OpenSBI release is listed in the NVD entry at the time of publication. Track the OpenSBI project for a fix addressing the SBI function #2 and PMU counter-match handling. Downstream distributions and board vendors should rebase to a patched release once available.

Workarounds

Disable the SBI PMU extension in OpenSBI builds when performance counters are not required by the workload
Filter SBI PMU calls at the hypervisor or supervisor layer to reject malformed counter configuration arguments
Isolate untrusted workloads from hardware running vulnerable OpenSBI firmware until a patch is applied

bash

# Rebuild OpenSBI without the PMU extension as a temporary mitigation
make PLATFORM=generic FW_OPTIONS=0x2 \
     CFLAGS="-DOPENSBI_DISABLE_PMU"