XiangShan CVE-2026-29642

Requires execution of privileged RISC-V M-mode (Machine Mode) instructions - the highest privilege level in RISC-V architecture, equivalent to firmware or hypervisor context, not accessible to operating system kernels or user applications. Attacker must either (1) directly execute code in M-mode via compromised bootloader, secure monitor, or hypervisor, or (2) induce M-mode firmware to perform the vulnerable csrrs operations on menvcfg register through exploitation of another vulnerability or firmware interface. Exploitation requires deep knowledge of RISC-V CSR architecture, specifically menvcfg register layout and WPRI field positions in the XiangShan implementation. Limited to systems using affected XiangShan processor core versions (commit aecf601e80, November 2024, through the fix at 5e3dd63). The PR:L privilege requirement in CVSS vector conflicts with actual M-mode requirement described - real exploitation barrier is significantly higher than low-privilege user access.

Real-world risk is significantly lower than the CVSS 7.8 base score suggests. The CVSS vector (AV:L/AC:L/PR:L/UI:N/S:U) indicates local access with low-privilege user, but the description clarifies that execution of privileged M-mode CSR operations is required - RISC-V M-mode is the highest privilege level, equivalent to hypervisor or firmware context, not a regular user account. This represents a fundamental discrepancy: PR:L (low privilege) conflicts with the requirement for machine-mode access. The EPSS score of 0.02% (5th percentile) aligns with the realistic attack surface - attackers must already have firmware-level code execution or ability to manipulate bootloader/hypervisor CSR operations. No CISA KEV listing, no public POC, and exploitation requires deep RISC-V architectural knowledge plus existing privileged access make this primarily a defense-in-depth issue for embedded systems and SoC vendors using XiangShan cores. The corruption of xstatus register bits could theoretically enable privilege escalation or security feature bypass in multi-tenant firmware environments, but practical impact depends on how downstream implementations utilize these status bits. Primary concern is for hardware vendors integrating XiangShan into production silicon rather than end-user systems. Patch availability via upstream commit (5e3dd63) mitigates risk for development teams, though integration into tagged releases and vendor SoC firmware updates may lag significantly.

An attacker with compromised bootloader or hypervisor code (M-mode execution) on a system using vulnerable XiangShan core crafts a sequence of csrrs instructions targeting menvcfg register with specific bit patterns. These operations unexpectedly corrupt the processor's xstatus register by setting reserved WPRI bits, potentially disabling security features tracked in status bits or creating inconsistent privilege state. The attacker leverages this corrupted processor state to bypass security checks in subsequent firmware code, escalate privileges, or leak sensitive data from higher privilege contexts. Given the requirement for pre-existing M-mode access, this vulnerability is most relevant as a privilege persistence mechanism after initial compromise rather than an initial access vector.