CVE-2026-29642: XiangShan Privilege Escalation Vulnerability

CVE-2026-29642 Overview

A hardware-level vulnerability exists in the XiangShan RISC-V processor implementation where privileged Control and Status Register (CSR) operations targeting menvcfg can unexpectedly corrupt WPRI (Write Preserve, Read Ignore) reserved bits in the status view (xstatus). This vulnerability allows a local attacker with the ability to execute privileged CSR operations in M-mode—or induce firmware to perform such operations—to manipulate processor state in ways that violate the RISC-V specification.

The root cause lies in improper interaction logic between the SDT (Supervisor Double Trap) field and the DTE (Double Trap Enable) control bit within the menvcfg register handling. When carefully crafted csrrs instructions are executed, the processor incorrectly propagates writes to reserved fields that should remain unchanged per RISC-V privileged architecture specification.

Critical Impact

Successful exploitation enables corruption of processor reserved state bits, potentially leading to privilege escalation, security control bypass, or undefined processor behavior in affected XiangShan implementations.

Affected Products

• XiangShan RISC-V Processor (commit aecf601e803bfd2371667a3fb60bfcd83c333027, 2024-11-19)
• OpenXiangShan implementations using affected CSR handling logic
• Systems running firmware that performs M-mode CSR operations on vulnerable XiangShan cores

Discovery Timeline

• 2026-04-20 - CVE CVE-2026-29642 published to NVD
• 2026-04-21 - Last updated in NVD database

Technical Details for CVE-2026-29642

Vulnerability Analysis

This vulnerability represents a violation of the RISC-V privileged architecture specification regarding WPRI field handling in Control and Status Registers. WPRI fields are defined as "writes preserve values, reads ignore values," meaning software operations on other fields within the same register must not modify these reserved bits. The XiangShan implementation fails to properly isolate write operations, allowing menvcfg accesses to unexpectedly set WPRI bits in xstatus to 1.

The flaw specifically affects the interaction between the SDT (Supervisor Double Trap) field and the DTE (Double Trap Enable) control mechanism. The original implementation incorrectly allowed alias writes through sstatus to propagate to mstatus.SDT even when menvcfg.DTE was disabled, violating the specification requirement that menvcfg.DTE should control S-mode double trap behavior exclusively.

Root Cause

The vulnerability stems from incorrect conditional logic in the CSR write handling for the double trap (dbltrp) interaction between menvcfg and mstatus. The original implementation calculated writeSDT without properly gating alias writes through sstatus based on the DTE enable bit state. Additionally, when DTE was disabled, the register output was incorrectly forced to false rather than preserving the existing register value during alias write operations.

The CWE-1244 (Internal Asset Exposed to Unsafe Debug Access Level) classification indicates this is fundamentally a hardware design flaw where internal processor state can be manipulated through improper debug or privileged access paths.

Attack Vector

An attacker requires local access with the ability to execute M-mode privileged instructions or the capability to induce firmware to perform specific CSR operations. The attack leverages csrrs (CSR Read and Set) instructions targeting menvcfg with carefully crafted bit patterns that trigger the faulty write propagation logic.

The following patch demonstrates the fix applied to correct the SDT/DTE interaction logic:

   }
   // when DTE is zero, SDT field is read-only zero(write any, read zero, side effect of write 1 is block)
   val writeSDT = Wire(Bool())
-  writeSDT := Mux(this.menvcfg.DTE.asBool, (w.wdataFields.SDT && w.wen) || (wAliasSstatus.wdataFields.SDT && wAliasSstatus.wen), 0.U)
-  when (!this.menvcfg.DTE) {
-    regOut.SDT := false.B
+  writeSDT := (w.wdataFields.SDT && w.wen) || (this.menvcfg.DTE.asBool && wAliasSstatus.wdataFields.SDT && wAliasSstatus.wen)
+  // menvcfg.DTE only control Smode dbltrp. Thus mstatus.sdt will not control by DTE.
+  // as sstatus is alias of mstatus, when menvcfg.DTE close write,
+  // sstatus.sdt cannot lead to shadow write of mstatus.sdt. \\
+  // As a result, we add wmask of sdt, when write source is from alias write.
+  when (!this.menvcfg.DTE.asBool && wAliasSstatus.wdataFields.SDT && wAliasSstatus.wen ) {
+    reg.SDT := reg.SDT
   }
   // SDT and SIE is the same as MDT and MIE
   when (writeSDT) {

Source: OpenXiangShan Commit Details

Detection Methods for CVE-2026-29642

Indicators of Compromise

• Unexpected values in WPRI fields of mstatus or sstatus registers when read
• Anomalous processor state after menvcfg CSR operations
• Firmware or software crashes related to unexpected privilege state transitions
• Double trap handling failures in S-mode execution contexts

Detection Strategies

• Implement hardware simulation tests that verify WPRI field preservation during CSR operations
• Monitor for unexpected changes in processor status registers during security-sensitive operations
• Deploy firmware integrity checks that validate expected CSR field values after privileged operations
• Use RISC-V compliance testing suites to verify correct WPRI behavior on deployed hardware

Monitoring Recommendations

• Establish baseline CSR register values and monitor for deviations in security-critical fields
• Implement logging for M-mode CSR operations targeting menvcfg in firmware
• Deploy anomaly detection for privilege level transitions that may indicate exploitation
• Monitor system stability metrics that could indicate processor state corruption

How to Mitigate CVE-2026-29642

Immediate Actions Required

• Update XiangShan implementations to include commit 5e3dd63 or later containing the security fix
• Review firmware that performs menvcfg CSR operations for potential exploitation paths
• Audit custom M-mode software for CSR operation sequences that could trigger the vulnerability
• Consider restricting M-mode CSR access in multi-tenant or untrusted execution environments

Patch Information

The OpenXiangShan project has released a fix addressing this vulnerability. The patch corrects the SDT/DTE interaction logic in src/main/scala/xiangshan/backend/fu/NewCSR/MachineLevel.scala to properly gate alias writes and preserve register values when DTE is disabled. Technical details are available in the OpenXiangShan Issue Discussion and the OpenXiangShan Commit Details.

For additional context on RISC-V privileged CSR specifications, refer to the RISC-V Machine Instruction Reference and RISC-V Privileged CSRs Reference.

Workarounds

• Implement firmware-level validation of WPRI field integrity after CSR operations as a defense-in-depth measure
• Restrict M-mode execution to trusted code paths only until patches can be applied
• Consider deploying hardware security modules or isolation mechanisms for critical workloads on affected systems
• Monitor for exploitation attempts while awaiting hardware updates in deployed systems

# Verification: Check XiangShan commit version for patched CSR handling
cd XiangShan
git log --oneline src/main/scala/xiangshan/backend/fu/NewCSR/MachineLevel.scala | grep -E "5e3dd63|dbltrp|sdt"