CVE-2026-29649: NEMU RISC-V Hypervisor DoS Vulnerability

CVE-2026-29649 Overview

CVE-2026-29649 is a critical implementation flaw in NEMU's RISC-V Hypervisor Control and Status Register (CSR) handling. The vulnerability exists in how henvcfg[7:4] (CBIE/CBCFE/CBZE-related fields) is incorrectly masked and updated based on menvcfg[7:4]. This flaw allows a machine-mode write to menvcfg to implicitly modify the hypervisor's environment configuration, leading to incorrect enforcement of virtualization configuration and potentially causing unexpected traps or denial of service when executing cache-block management instructions in virtualized contexts (V=1).

Critical Impact

Attackers can exploit this CSR handling flaw to disrupt virtualized environments by manipulating hypervisor configuration, leading to denial of service or unexpected system behavior in RISC-V virtualization contexts.

Affected Products

• NEMU (NJU Emulator) - RISC-V Hypervisor Extension Implementation

Discovery Timeline

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

Technical Details for CVE-2026-29649

Vulnerability Analysis

This vulnerability stems from a Protection Mechanism Failure (CWE-693) in NEMU's implementation of the RISC-V Hypervisor Extension. The RISC-V privileged architecture defines strict hierarchical relationships between machine-mode and hypervisor-mode environment configuration registers. According to the RISC-V specification, henvcfg (hypervisor environment configuration) should be independent from menvcfg (machine environment configuration) writes, except through explicit software control.

The flawed implementation incorrectly couples the masking behavior of henvcfg[7:4] fields—which control cache-block instruction enable (CBIE), cache-block clean/flush enable (CBCFE), and cache-block zero enable (CBZE)—to the corresponding bits in menvcfg[7:4]. This means when machine-mode software modifies menvcfg, it can inadvertently alter the hypervisor's cache-block management policy without explicit hypervisor consent.

Root Cause

The root cause is an incorrect dependency between machine-mode and hypervisor-mode CSR updates in NEMU's CSR handling logic. The implementation erroneously applies menvcfg[7:4] as a mask to henvcfg[7:4] during CSR write operations, violating the RISC-V privileged specification's requirement for independent configuration register management between privilege levels. This architectural violation allows implicit cross-privilege configuration modifications that should be prohibited by design.

Attack Vector

The attack vector leverages the network-accessible nature of virtualized RISC-V environments running on NEMU. An attacker who can execute code at machine mode, or influence machine-mode operations, can craft writes to menvcfg that will implicitly modify henvcfg fields. When a guest operating system subsequently attempts to execute cache-block management instructions (CBO.INVAL, CBO.CLEAN, CBO.FLUSH, CBO.ZERO) in virtualized mode (V=1), the incorrect henvcfg configuration can cause:

1. Unexpected illegal instruction traps when instructions should be permitted
2. Allowed execution of instructions that should be prohibited
3. System instability or crashes in the virtualized environment

The vulnerability is exploitable without user interaction and requires no prior authentication, as the flawed CSR handling logic is inherent to the emulator's operation.

Detection Methods for CVE-2026-29649

Indicators of Compromise

• Unexpected illegal instruction exceptions when executing cache-block instructions (CBO.INVAL, CBO.CLEAN, CBO.FLUSH, CBO.ZERO) in virtualized guests
• Inconsistent henvcfg register values that do not match expected hypervisor configuration
• Guest VM crashes or instability following machine-mode CSR write operations to menvcfg
• Anomalous trap behavior in V=1 (virtualization mode enabled) contexts

Detection Strategies

• Monitor CSR write operations to menvcfg and correlate with subsequent henvcfg state changes
• Implement runtime checks comparing expected vs actual henvcfg[7:4] field values after menvcfg modifications
• Deploy hypervisor integrity monitoring to detect unauthorized configuration changes
• Enable verbose logging for cache-block instruction traps in virtualized environments

Monitoring Recommendations

• Configure RISC-V debug facilities to trace CSR read/write operations on menvcfg and henvcfg
• Implement alerting for unexpected illegal instruction traps on cache-block management instructions
• Monitor system logs for patterns indicating virtualization configuration inconsistencies
• Deploy endpoint detection capabilities that can identify anomalous RISC-V emulator behavior

How to Mitigate CVE-2026-29649

Immediate Actions Required

• Review deployed NEMU instances for exposure to untrusted workloads
• Consider isolating affected RISC-V virtualization environments until patches are applied
• Audit machine-mode code for menvcfg write operations that could trigger the vulnerability
• Implement additional access controls to restrict machine-mode CSR modifications where possible

Patch Information

The vulnerability has been addressed through GitHub Pull Request #689 which corrects the CSR masking behavior. The fix ensures that henvcfg[7:4] fields are updated independently of menvcfg[7:4] writes, aligning with the RISC-V Hypervisor Extension specification. Organizations running NEMU should update to a version containing this fix. The issue was originally reported in GitHub Issue #681.

Workarounds

• Avoid running untrusted code at machine privilege level on affected NEMU instances
• Implement wrapper functions around menvcfg writes that explicitly restore correct henvcfg values
• Consider using alternative RISC-V emulators for security-sensitive virtualization workloads until the patch is applied
• Disable cache-block management instructions in guest VMs if not required for operation

# Verify NEMU version and check if patch PR #689 is included
cd /path/to/NEMU
git log --oneline | grep -i "henvcfg\|689\|menvcfg" | head -10

# If using an unpatched version, consider building from latest source
git fetch origin
git log origin/master --oneline | grep -i "689"