CVE-2026-29643: XiangShan RISC-V Processor DoS Vulnerability

CVE-2026-29643 Overview

CVE-2026-29643 is an improper exceptional-condition handling vulnerability in the XiangShan open-source high-performance RISC-V processor. The flaw exists in the Control and Status Register (CSR) subsystem, specifically within the NewCSR component. When certain sequences of CSR operations target non-existent or custom CSR addresses, the processor may trigger an illegal-instruction exception but fail to reliably transfer control to the configured trap handler (mtvec). This control-flow disruption can leave the processor core in a hung or unrecoverable state.

The vulnerability affects commit edb1dfaf7d290ae99724594507dc46c2c2125384 dated 2024-11-28 and potentially other versions. A local attacker with the ability to execute code on the processor can exploit this flaw to cause a denial of service and potentially introduce inconsistent architectural state.

Critical Impact

Local attackers can execute specific CSR instruction sequences to crash or hang the processor core, causing denial of service and potential architectural state corruption in affected XiangShan RISC-V implementations.

Affected Products

• XiangShan RISC-V Processor commit edb1dfaf7d290ae99724594507dc46c2c2125384 (2024-11-28)
• Potentially other XiangShan versions with the vulnerable NewCSR subsystem implementation

Discovery Timeline

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

Technical Details for CVE-2026-29643

Vulnerability Analysis

This vulnerability is classified under CWE-703 (Improper Check or Handling of Exceptional Conditions). The root issue lies in how the XiangShan processor's CSR subsystem handles exceptional conditions when processing CSR instructions that reference non-existent or custom register addresses.

In RISC-V architecture, CSR instructions that access invalid or unimplemented registers should generate an illegal instruction exception, with control transferring to the address specified in the mtvec (Machine Trap-Vector Base-Address) register. However, the vulnerable implementation in XiangShan's NewCSR subsystem fails to properly complete this exception handling sequence under certain conditions.

The vulnerability requires local access, meaning an attacker must be able to execute code directly on the affected processor. While this limits the attack surface, it presents serious concerns for systems where untrusted code may execute, such as multi-tenant environments or systems running potentially malicious applications.

Root Cause

The root cause is an improper exceptional-condition handling flaw in the NewCSR subsystem of the XiangShan processor. When specific sequences of CSR operations target non-existent or custom CSR addresses, the exception handling mechanism fails to reliably transfer control to the trap handler configured via mtvec. This indicates a defect in the processor's trap dispatch logic or state machine that handles illegal instruction exceptions for CSR operations.

The RISC-V specification requires that illegal CSR accesses generate synchronous exceptions with proper control transfer to the trap handler. The XiangShan implementation does not meet this requirement under certain edge-case instruction sequences, violating the expected architectural behavior defined in the RISC-V Privileged Control and Status Registers specification.

Attack Vector

The attack vector is local, requiring an attacker to execute code on the target processor. Exploitation involves crafting specific sequences of CSR instructions that target non-existent or custom CSR addresses. When executed, these instruction sequences trigger the vulnerable code path in the NewCSR subsystem, causing the processor to enter a hung or unrecoverable state.

The attack can be performed by any local user with code execution capabilities on the processor. This could include:

• Unprivileged user-space applications on systems with direct hardware access
• Virtual machine guests in virtualized environments
• Embedded system firmware or applications

Technical details about the specific instruction sequences and the fix can be found in GitHub Issue #3959 and GitHub Pull Request #3966.

Detection Methods for CVE-2026-29643

Indicators of Compromise

• Unexpected processor core hangs or freezes during normal operation
• System watchdog timeouts indicating unresponsive cores
• Kernel panic or crash logs referencing illegal instruction exceptions that did not properly transfer to trap handlers
• Repeated system reboots without clear software-level cause

Detection Strategies

• Monitor for abnormal system stability issues on XiangShan-based platforms
• Implement hardware watchdog timers to detect and recover from processor hangs
• Review execution logs for patterns of illegal instruction exceptions followed by system instability
• Deploy runtime monitoring for CSR instruction patterns that target unusual or custom register addresses

Monitoring Recommendations

• Enable hardware performance counters to track illegal instruction exception rates
• Configure watchdog mechanisms with appropriate timeout thresholds
• Implement system health monitoring that can detect processor core hangs
• Log and analyze any recovery events from watchdog-triggered resets

How to Mitigate CVE-2026-29643

Immediate Actions Required

• Update XiangShan processor implementation to a version containing the fix from Pull Request #3966
• Review any custom CSR implementations for similar exception handling issues
• Implement watchdog timers to detect and recover from potential processor hangs
• Limit code execution capabilities to trusted applications where possible

Patch Information

The vulnerability has been addressed in the XiangShan project. The fix is available in GitHub Pull Request #3966. Users should update their XiangShan implementation to a commit that includes this fix. The patch corrects the exceptional-condition handling in the NewCSR subsystem to ensure proper control transfer to the trap handler when illegal CSR accesses occur.

For additional technical context, refer to the RISC-V Machine Instruction Set documentation and the RISC-V Privileged CSR specification.

Workarounds

• Implement hardware watchdog timers to automatically reset the processor if it becomes unresponsive
• Restrict code execution on affected systems to trusted applications only
• Consider deploying redundant processor configurations where high availability is required
• Monitor systems for unusual stability issues and investigate potential exploitation attempts

# Example: Enable hardware watchdog on Linux systems with XiangShan processors
# This provides automatic recovery if the processor enters a hung state
# Note: Specific commands depend on system configuration

# Check if watchdog device is available
ls -la /dev/watchdog*

# Configure watchdog timeout (example for systems with watchdog support)
echo 30 > /sys/class/watchdog/watchdog0/timeout