CVE-2025-63384: RISC-V Rocket-Chip Privilege Escalation

CVE-2025-63384 Overview

CVE-2025-63384 affects the RISC-V Rocket-Chip processor implementation version 1.6 and earlier. The vulnerability resides in the handling of the SRET (Supervisor-mode Exception Return) instruction. The processor fails to correctly downgrade its privilege level when executing SRET from Machine-mode (M-mode). Instead of transitioning to Supervisor-mode (S-mode) as dictated by the sstatus.SPP bit, the core retains M-mode privileges. This behavior contradicts the RISC-V privileged architecture specification and creates a privilege retention flaw [CWE-266].

Critical Impact
Code executing after an SRET instruction can retain Machine-mode privileges, bypassing the intended privilege boundary between M-mode firmware and S-mode operating system kernels.

Affected Products

Chipsalliance Rocket-Chip v1.6
Chipsalliance Rocket-Chip versions prior to v1.6
RISC-V systems built on the affected Rocket-Chip generator

Discovery Timeline

2025-11-10 - CVE-2025-63384 published to NVD
2026-06-17 - Last updated in NVD database

Technical Details for CVE-2025-63384

Vulnerability Analysis

The RISC-V privileged specification defines SRET as the instruction used to return from a supervisor-mode trap. When executed, the processor must set its current privilege level to the value stored in the sstatus.SPP field. In the Rocket-Chip implementation, this transition is not performed correctly when SRET is executed from Machine-mode.

The processor should either raise an illegal instruction exception or correctly downgrade the privilege level based on the specification. Instead, the core continues execution with M-mode privileges retained. Machine-mode is the highest privilege level in RISC-V, with unrestricted access to physical memory, control and status registers (CSRs), and hardware peripherals.

Code that was intended to run under supervisor-mode isolation therefore inherits full hardware access. This undermines the trust boundary that separates the Secure Machine-mode Interface (SMI) firmware from the operating system kernel and its userspace.

Root Cause

The root cause is incorrect implementation of the privilege transition logic in the Rocket-Chip control path. The hardware does not honor the semantics of sstatus.SPP when SRET executes from a privilege level higher than S-mode. The condition maps to [CWE-266] Incorrect Privilege Assignment.

Attack Vector

An authenticated attacker with the ability to influence M-mode execution flow, or code paths that reach an SRET instruction from M-mode context, can retain elevated privileges. The result is bypass of S-mode isolation and potential compromise of confidentiality across processes and hypervisor guests running on the affected hardware.

No working exploit is publicly available and CISA KEV does not list this issue. Refer to the GitHub Vulnerability Disclosure for the technical reproducer discussion.

Detection Methods for CVE-2025-63384

Indicators of Compromise

Unexpected access to Machine-mode CSRs such as mstatus, mepc, or mtvec from code paths that should be running in S-mode or U-mode.
Kernel or hypervisor logs showing successful reads or writes to physical memory regions protected by Physical Memory Protection (PMP).
Anomalous execution traces where SRET is followed by instructions that require M-mode without an intervening trap.

Detection Strategies

Perform RTL simulation and formal verification of the SRET instruction path to confirm correct privilege transitions across all originating modes.
Instrument test benches with directed and random privilege-transition sequences and assert the post-SRET privilege level matches sstatus.SPP.
Audit synthesized cores against the RISC-V Architectural Compatibility Test (ACT) suite for privileged-mode compliance.

Monitoring Recommendations

Monitor firmware and boot logs for unexpected privilege escalations following supervisor exception returns.
Track upstream commits and issues in the Rocket-Chip repository for fixes referencing SRET semantics.
Correlate abnormal PMP violation counters with process context switches to identify anomalous privilege state.

How to Mitigate CVE-2025-63384

Immediate Actions Required

Inventory deployed systems and FPGA bitstreams built from Rocket-Chip v1.6 or earlier and identify workloads that depend on strict M-mode/S-mode isolation.
Restrict trusted M-mode firmware to avoid code paths that execute SRET outside intended supervisor return flows.
Rebuild affected cores from a patched Rocket-Chip revision once the maintainers publish a corrected privilege transition.

Patch Information

At the time of publication, no vendor advisory or fixed release is referenced in the NVD entry. Organizations building custom silicon or FPGA images from Rocket-Chip should track the upstream Rocket-Chip repository and the vulnerability disclosure notes for the corrective commit. Redeployment requires resynthesis of the RTL and reflashing of bitstreams or respinning of ASIC designs.

Workarounds

Audit M-mode firmware and SBI implementations to ensure SRET is only executed after correct restoration of sstatus.SPP and only from intended trap-return handlers.
Constrain workloads to trusted software stacks until a corrected RTL revision is deployed on affected hardware.
Apply defense-in-depth by tightening PMP configurations to reduce the blast radius of code executing with unintended M-mode privileges.

bash

# Configuration example
# Track upstream Rocket-Chip for the corrective commit
git clone https://github.com/chipsalliance/rocket-chip.git
cd rocket-chip
git log --all --grep="SRET" --oneline