SOURCE ARCHIVE
EXTRACTED CONTENT
70,452 charsRISCSmith: Finding RISC-V CPU Bugs via Rich Instruction Construction and On-the-fly Differential Analysis
Xudong Zhang†, Yuanliang Chen†B, Zehong Yu†, Zhen Yan†, Fuchen Ma†, Dalong Shi‡, Yu Jiang†B † KLISS, BNRist, School of Software, Tsinghua University, Beijing, China ‡ Aviation Industry Corporation of China Ltd., Beijing, China Abstract With the increasing adoption of open-source RISC-V CPUs and Processors are the foundation of all computing systems, yet complex the high cost of formal verification, hardware fuzzing has gained RTL and microarchitectural front ends make logic defects difficult to significant traction [5, 17, 20, 31, 34, 38, 39]. CPU fuzzers typically eliminate and extremely costly to fix after tape-out. Although RISC- generate random instruction sequences or mutate existing programs V fuzzing has revealed many bugs in practice, existing approaches to explore new processor behaviors, and then compare execution remain limited: they rely on manually maintained instruction models against a reference model such as Spike [30] to detect state differences and generate insufficiently rich CPU test programs. Moreover, they and reveal design defects. Existing fuzzers have uncovered many bugs lack precise register and memory monitoring, and either perform high- in real processor implementations, including Rocket [9], BOOM [3], overhead per-instruction differential checks or coarse end-of-program and CVA6 [11], improving the security and reliability of the RISC-V comparisons – both making bug analysis and localization inefficient. hardware ecosystem. In this work, we propose RISCSmith (30K+ Rust LoC), a fuzzing However, current tools face the following limitations. (1) Incom- framework aimed at detecting bugs in RISC-V CPUs. First, RISCSmith plete Instruction Modelling: Given RISC-V continues to evolve automatically builds rich instruction models by parsing the RISC-V rapidly, hand-maintained instruction models struggle to completely UnifiedDB to extract structured instruction metadata, resolve incon- cover full instruction sets, leaving substantial functionality unex- sistencies, and generate strongly typed models capturing operand ploited. Generated programs often lack proper register or memory roles and runtime semantics. Second, RISCSmith instruments RISC-V initialization (e.g., memory instructions using base registers that were implementations with lightweight logging to collect per-instruction never assigned valid addresses), and instructions rarely interact on register, memory, and exception data, performing on-the-fly differ- shared data, making it difficult to form meaningful dependencies. As ential analysis to pinpoint the first divergence, classify its cause, and a result, the overall quality of the test cases remains limited. (2) In- minimize the reproducing test case. We implemented and evaluated sufficient Bug Detection: For bug detection, existing approaches RISCSmith on six widely used RISC-V CPUs. In total, it uncovered 18 either halt after every instruction to compare architectural state (e.g., previously unknown bugs. Compared to state-of-the-art CPU fuzzers register values), which introduces significant runtime overhead, or like Cascade and RISCV-DV, RISCSmith detects 3.5x and 2.6x more compare only at program completion, which misses the first point bugs and covers 37% and 61% more branches, respectively. of divergence and the detailed mismatch. In addition, while these ACM Reference Format: methods typically perform precise comparison of register differences, Xudong Zhang†, Yuanliang Chen†B, Zehong Yu†, Zhen Yan†, Fuchen Ma†, memory checking is often coarse-grained and can overlook subtle Dalong Shi‡, Yu Jiang†B. 2026. RISCSmith: Finding RISC-V CPU Bugs via errors. Rich Instruction Construction and On-the-fly Differential Analysis. In 63rd Existing CPU Fuzzers RISCSmith ACM/IEEE Design Automation Conference (DAC ’26), July 26–29, 2026, Long Instruction Modeling Differential Analysis Rich Instruction On-the-Fly Differential Construction Analysis Beach, CA, USA. ACM, New York, NY, USA, 7 pages. https://doi.org/10.1145/ Manual reading of RISC-V CPU Automatically parse the RISC-V CPU with RISC-V spec Under Test RISC-V Uni compile-time 3770743.3803916 fied Database instrumentation 1 Introduction RISC-V instruction Manually adapt Compare registers per- Automatically Model instruction with pauses Or RISC-V instruction Compare register and memory writes per Processors form the foundation of modern computing systems. The Compare registers only at instruction, no pauses, Fewer extensions and program end Rich extensions and low overhead growing complexity of their design–such as multi-stage pipelines instructions instructions and speculative execution [6, 8, 40]–has led to numerous security Low ef ficiency, precise ficiency, coarse High ef Instruction test inputs memory monitoring Instruction test inputs memory monitoring vulnerabilities [19, 21, 25]. Detecting such bugs before fabrication is critical to prevent severe consequences, including substantial financial Figure 1: Comparison between RISCSmith and existing CPU losses [1, 18]. However, exhaustive pre-silicon verification (i.e., testing fuzzers. RISCSmith automatically models rich RISC-V instruc- all possible scenarios) remains infeasible due to the vast state space of tions and efficiently analyzes fine-grained memory and register modern processors [5]. differences with low overhead. In this work, we propose RISCSmith, a framework for detecting Yuanliang Chen and Yu Jiang are the corresponding authors. RISC-V CPU bugs through rich instruction construction and on-the-fly differential analysis. Our key insight is to leverage the RISC-V Uni- fiedDB to generate rich instruction sequences based on authoritative This work is licensed under a Creative Commons Attribution 4.0 International License. and up-to-date instruction specification, and employ low-instruction DAC ’26, Long Beach, CA, USA logging instrumentation to enable efficient differential analysis. (1) To © 2026 Copyright held by the owner/author(s). enable rich instruction modelling, RISCSmith first parses the RISC-V ACM ISBN 979-8-4007-2254-7/2026/07 UnifiedDB, and authoritative and up-to-date specification, to extract https://doi.org/10.1145/3770743.3803916
DAC ’26, July 26–29, 2026, Long Beach, CA, USA Xudong Zhang†, Yuanliang Chen†B, Zehong Yu†, Zhen Yan†, Fuchen Ma†, Dalong Shi‡, Yu Jiang†B
concise and structured instruction metadata, including instruction where either the Prefix or Suffix is removed, the store succeeds. Only
encoding, operands and access semantics. RISCSmith then reconciles by reproducing the dependency between surrounding instructions
naming difference, resolves inconsistencies, and constructs strongly can differential comparison expose this deviation.
typed instruction models that capture operand roles, type constraints, Trapping instructions Non-trapping instructions Other Instructions
and runtime semantics. (2) To enable high-efficiency bug analysis, Scenario A (bug) Scenario B Scenario C
RISCSmith instruments RISC-V implementations with lightweight
logging hooks. RISCSmith captures memory updates, register writes, Prefix: Read CSR to xreg Prefix: Read CSR to xreg
csrr x19, mseccfg csrr x19, mseccfg No Instructions
and exceptions to reconstruct instruction execution context, and per- csrr x19, pmpcfg0 csrr x19, pmpcfg0
forms on-the-fly comparison between the target implementation and ... ...
the reference model to localize the first divergence. Finally, RISCSmith Core: Store to user addr Core: Store to user addr Core: Store to user addr
li x2, 0x8fffffdc li x2, 0x8fffffdc li x2, 0x8fffffdc
determines dependency relationships leading to the mismatch, classi- li x3, 0x0 li x3, 0x0 li x3, 0x0
sb x3, 0(x2) sb x3, 0(x2) sb x3, 0(x2)
fies the divergence type, and automatically minimizes the instruction Suffix: Hypervisor load Suffix: Hypervisor load
sequence into a reproducible test case. hlvx.hu x20, 0(x2) No Instructions hlvx.hu x20, 0(x2)
We conducted experiments on six real-world RISC-V CPUs, i.e. Pi- Figure 2: CVA6 memory-permission bug: the store triggers
coRV32 [14], CVA6 [11], VexRiscv [13], Rocket [9], Xiangshan [12], and LD_ACCESS_FAULT only in Scenario A, where it is enclosed by
Kronos [35]. RISCSmith has discovered 18 new bugs. Compared with PMP CSR (Prefix) and the hypervisor load hlvx.hu (Suffix).
other SOTA CPU fuzzers such as Cascade [34], and RISCV-DV [31], This bug exposes two key weaknesses in existing RISC-V test-
RISCSmith detects 3.5x and 2.6x more bugs, covers 37% and 61% more ing methods and the improvements needed. (1) Manual instruction
branches. In summary, we make three contributions:• modeling cannot keep up with expanding extensions – unsupported
We propose a rich RISC-V instruction model automatically con- operations like hlvx.hu often lack proper register or memory setup,
• structed from the UnifiedDB. leaving instructions to access inconsistent addresses. To overcome this,
We design an on-the-fly differential analysis with low-overhead automated modeling is needed to cover rich instructions, generate
• instrumentation to monitor differences precisely. constrained programs, and prepare valid contexts for multi-instruction
We implement and evaluate RISCSmith on six widely used RISC-V interaction. (2) Coarse differential comparison is either precise but
CPUs. We will open-source it1 for practical usage. Currently, it has slow with per-instruction pauses or fast but incomplete when check-
2 already detected 18 new bugs. ing only end states, missing early divergences such as misclassified sb
Background And Motivation traps. This calls for high-speed execution with fine-grained logging
RISC-V is an open, modular ISA whose base and rich standard that captures per-instruction register, memory, and exception data,
extensions (M/A/F/D/C/V/H and many Z*/S* series) support deploy- precisely localizing divergences with low overhead.
ments from embedded devices to high-performance computing, and 3
whose open ecosystem has produced diverse implementations such as Design
Spike, Rocket, CVA6, and XiangShan. To keep these rapidly evolving Design goal: A practical RISC-V CPU fuzzing framework should implementations aligned with the specification, the RISC-V Unified have the following properties.• Database (UnifiedDB) provides an official, unified, and trustworthy General: RISCSmith is designed to detect bugs in a wide range of data source that precisely describes, using structured YAML and JSON practical RISC-V CPUs and supports mainstream RISC-V architec- Schema, the encoding, operand constraints, and IDL semantics of tures such as RV32IMC, RV64IMAC, RV64GC, and RV64IMAFDC. all standard extensions, instructions, and CSRs. Its modular version- The tool can be rapidly deployed to test different RISC-V CPU ar- ing and support for custom extensions ensure traceability of spec • chitectures with only minor configuration adjustments. evolution and extensibility, while giving data-driven modeling and Efficient: RISCSmith is able to frequently exercise the CPUs and verification tools a stable foundation that automatically inherits the • effectively detect bugs in real-world RISC-V CPUs in 24 hours. latest definitions as the RISC-V instruction specification evolves. Accurate: RISCSmith is designed to have satisfying precision and In large RISC-V processor projects, pipeline, memory, and permis- 3.1recall to avoid reporting false positives. sion control logic are tightly coupled. If pre-silicon verification misses RISCSmith Workflow such issues, architecture-level divergences discovered after tape-out Figure 3 illustrates the workflow of RISCSmith, consisting of two may require costly ECOs; hence, strong verification confidence must main stages. Instruction Modelling stage. (1) RISCSmith first parses be achieved early. A memory-permission defect we found in CVA6 il- the RISC-V UnifiedDB to extract each instruction’s encoding, operands, lustrates this risk. Figure 2 compares three scenarios that differ only in immediates, and access semantics, producing structured instruction whether PMP CSR probing (Prefix) and the hypervisor load hlvx.hu data. (2) It then reconciles naming differences, resolves inconsistencies, (Suffix) surround the same user-mode store (Core). Each column shows and builds strongly typed instruction models that encode operand the Prefix CSR reads, the Core store, and the Suffix load, with colors roles, type constraints, and runtime semantics. (3) These models are marking trapping and non-trapping instructions. In Scenario A (bug), integrated into a unified rich RISC-V instruction model, which serves as CSR reads such as mseccfg, pmpcfg, and pmpaddr precede a user- the foundation for the testcase generator. The generator automati- mode store followed by hlvx.hu; CVA6 incorrectly traps the store cally constructs programs that initialize register and memory contexts, as LD_ACCESS_FAULT even though the address is valid in user space, embed inter-instruction dependencies, and insert exception carry-on while Spike and Rocket both execute it correctly. In Scenarios B and C, templates. Differential Testing stage. (4) Source instrumentation. RISCSmith instruments the RISC-V implementation source by insert- 1 RISCSmith at: https://anonymous.4open.science/r/RISCSmith-EB85 ing lightweight logging hooks into the RTL. The instrumented code
RISCSmith: Finding RISC-V CPU Bugs via Rich Instruction Construction and On-the-fly Differential Analysis DAC ’26, July 26–29, 2026, Long Beach, CA, USA
Instruction modeling pipeline Generator Construction pinning memory accesses inside a known window. Integer, floating-
RISC-V Aggregate instructions & Exception carry-on point, CSR, shadow-stack, and compressed-instruction registers all
Uni
fied DB extensions per ISA template program
Parsing & Cleaning Pipeline Build strongly-typed instruction + follow the same validation rules, and configurations can be shared
models Register & memory init
Structured instruction program across projects as reusable templates that dramatically shorten tuning
Parse operands, syntax, and data +
type info Implement instruction syntax & time.
runtime type constraints
Testcase Generator
Fix naming, complete info, repair : During program synthesis the randomizer analyzes dependencies
syntax 1. Rich instruction set
2. Required memory/register init
Identify memory accesses and Generate Rich RISC-V Instruction Model 3. Inter-instruction correlated per instruction. Memory operations automatically receive "prepare
interaction
type constraints base and offset" snippets so computed addresses always fall inside
Source instrumentation Fine-grained Differential Analysis managed regions rather than accidentally reusing stale register values.
RISC-V implementation Precise divergence
source Logs: localization CSR, atomic, and arithmetic/logic instructions operate within the same
Per-instruction
Execution memory, registers,
Instrumented code with and exceptions Provide info Determine divergence narrow register and memory windows, forcing sequences to reuse
logging Post-processing dependency state; this deliberate crowding causes instructions to read, modify,
Verilator Instruction context: Divergence type and and rewrite the same locations repeatedly, which stresses coherence,
Per-instruction details
Low-overhead simulation memory/register Minimized reproducer of
program context divergence protection, and exception handling far more effectively than blindly
Figure 3: The workflow of RISCSmith. It includes two main increasing sequence length.
processes: (1)Rich RISC-V Instruction Automatic Construction To ensure the generated programs remain practical, RISCSmith
for generating high-quality instruction test inputs; (2) On-the- continuously assembles batches of random instructions that span
fly Differential Analysis for detecting bugs in CPUs. multiple extensions with the standard GNU RISC-V toolchain. Any
is compiled and simulated using Verilator to produce a low-overhead failing samples, build logs, and minimized reproducers are archived so execution environment capable of recording per-instruction events. the modeling team can react immediately. Custom extensions reuse (5) Fine-grained logging. During execution, RISCSmith captures de- the identical pipeline: providing UnifiedDB-style metadata is enough tailed logs of per-instruction memory updates, register writes, and to regenerate models, randomization policies, and runnable tests at exceptions. The collected data is then post-processed to reconstruct the same quality level as official extensions—no template rewrites or each instruction’s execution context, including its memory and reg- ad-hoc scripts required. ister state, forming a precise behavioral trace for later comparison. 3.3 On-the-fly Differential Analysis (6) Differential analysis. RISCSmith performs on-the-fly comparison RISCSmith conducts differential testing through a three-stage pipeline between the target implementation and the reference model to lo- that integrates low-overhead instrumentation, fine-grained execution calize the first divergence. It determines dependency relationships monitoring, and automated bug analysis. This design ensures accurate leading to the mismatch, classifies the divergence type, and automati- and reproducible divergence detection while keeping runtime over- cally minimizes the instruction sequence into a reproducible test case. head minimal, enabling continuous high-throughput testing across This process enables precise and efficient identification of semantic RISC-V CPU implementations. inconsistencies across different RISC-V CPU implementations. Lightweight Source Instrumentation. RISCSmith first instru- 3.2 Rich RISC-V Instruction Construction ments the RISC-V implementation source with minimal logging hooks RISCSmith’s modeling stack is fully data driven. Every UnifiedDB that record per-instruction register and memory writes as well as ex- entry is ingested to capture the owning extension, supported widths, ception events. The instrumented RTL is compiled through Verilator encoding fields, register aliases, immediate magnitudes, parity re- into a low-overhead simulation executable, ensuring that instruction- quirements, and forbidden constants. The importer reconciles stylistic level traces can be collected efficiently without disrupting the CPU’s differences across source documents, normalizes naming and letter original execution timing or semantics. It establishes the foundation case, fills in missing text when schema hints allow, and records prove- for accurate post-execution context reconstruction. nance whenever conflicts arise so downstream stages always consume Fine-grained Difference Detection. During simulation, RISC- a coherent, auditable dataset. For base-plus-offset instructions, the Smith captures detailed per-instruction logs, including memory up- assembler grammar is further dissected to flag fixed registers, se- dates, register writes, and exceptions. After execution, these logs are lectable registers, and pure offset fields so all consumers see the same normalized into unified instruction contexts representing the "before– trustworthy "instruction truth." instruction–after" state of every executed operation. The system then With this canonical view in place, the code generator evaluates compares these contexts across multiple implementations or against whether each instruction is shared between RV32 and RV64, then a golden reference model to precisely detect divergences in excep- emits layered type hierarchies that cover shared views as well as tion behavior, register state, or memory contents. This fine-grained architecture-specific splits. Every instruction receives its own data comparison enables early identification of semantic mismatches with structure; constrained registers or immediates are rewrapped into minimal false positives. bounded types that carry parity rules and forbidden sets, and display On-the-fly Bug Analysis. When RISCSmith detects a behavioral logic, legality checks, randomization hooks, and configuration wiring difference, whether in register state or memory content, it automati- are composed alongside them. A centralized configuration surface cally logs all executed RISC-V instructions from the target CPU, times- exposes register windows, memory ranges, immediate domains, and tamping and organizing them into a structured reproduction log. Using curated register lists so users can adjust generation policies without this log, RISCSmith attempts to deterministically reproduce the di- touching code—for instance limiting integer destinations to x8–x15 or vergence and applies a binary search–based minimization algorithm to isolate the shortest instruction sequence that consistently triggers
DAC ’26, July 26–29, 2026, Long Beach, CA, USA Xudong Zhang†, Yuanliang Chen†B, Zehong Yu†, Zhen Yan†, Fuchen Ma†, Dalong Shi‡, Yu Jiang†B
Table 1: 18 new bugs detected by the tools within 24 hours. RISCSmith found all 18 bugs. In comparison, Cascade found 4 bugs,
and RISCV-DV found 5 bugs, respectively. Identifiers are reported using public issue numbers.
# RISC-V CPUs Root Cause Analysis Location Identifier
1 PicoRV32 Misaligned load trap still commits a stale register writeback. Load misalignment trap PICO-278
2 PicoRV32 Misaligned store trap still drives AXI write strobes and corrupts memory. AXI-Lite write strobes PICO-279
3 PicoRV32 A byte load can read a stale byte from an older word, diverging from Spike. Byte-load data mux PICO-283
4 CVA6 AMO instructions never log the memory write in RVFI, only the register result. RVFI AMO trace logic CVA6-3130
5 CVA6 Div/sqrt ignores NaN-boxing, so unboxed NaNs are treated as normal numbers. CVFPU div/sqrt NaN-box path CVA6-3123
6 CVA6 RV32 div/sqrt truncates and re-boxes results, making fsqrt.s return NaN-boxed zero. RV32 single-precision sqrt datapath CVA6-2449
7 CVA6 FPU-to-integer ops write an integer register but the trace tags a FP register. RVFI int/FP writeback tagging CVA6-3122
8 CVA6 After PMP probing, sb followed by hlvx.hu is reported as a load fault instead of a store fault. PMP cache / LSU exception type CVA6-3126
9 CVA6 Hypervisor misaligned loads (e.g., hlv.d) encode the store/AMO misaligned cause instead of load misaligned. Hypervisor load cause encoder CVA6-3146
10 CVA6 Hypervisor misaligned stores (e.g., hsv.d) use a generic fault code instead of store/AMO misaligned. Hypervisor store cause encoder CVA6-3147
11 CVA6 With Zfa+FP16ALT, rm[2] is shared, so fleq.* can treat NaNs as normal FP16ALT values and return 1. FPU compare unit rm[2] mux CVA6-3145
12 VexRiscv FSGNJX.D uses a NaN-boxed rs2 with a cleared sign bit, so the XOR sign is wrong. FPU SGNJ sign/NaN-box path VEX-464
13 VexRiscv Writes to read-only CSRs cycle/instret retire without illegal-instruction. CSR read-only counter check VEX-465
14 Rocket RV32D fld uses 32-bit data_word_bypass, leaving the upper 32 bits of FP regs stale. FPU load data source ROCKET-3773
15 XiangShan For hlvx.hu, the TLB/exception logic prefers load guest-page fault (0x13) over load access fault (0x5). MMU hlvx permission / cause XS-5137
16 XiangShan AMOs on misaligned addresses raise store address misaligned (0x6) instead of store access fault (0x7). AMO exception vector / priorities XS-4667
17 XiangShan hvictl and time are treated as writable CSRs instead of trapping illegal writes. NewCSR hypervisor/time CSR checks XS-5248
18 Kronos Counter CSRs cycle/time/instret accept writes and do not raise illegal-instruction. Counter CSR write/illegal check KRONOS-20
the anomaly. If the minimized sequence reproduces the issue reli- heterogeneous RISC-V architectures, including RV32IMC, RV64IMAC,
ably, RISCSmith classifies it as a confirmed bug. Leveraging the fine- RV32IM, RV64IMAFDC, RV64GC, and RV32IMC/RV32EC, showcasing
grained source instrumentation introduced earlier, RISCSmith then RISCSmith’s generality across different pipeline depths, ISA exten-
maps each instruction input back to its corresponding RTL execution sions, and implementations.
trace, rapidly identifying the faulty logic and performing automated Table 2: Detailed information of target RISC-V CPUs
bug deduplication across different runs and CPU architectures to CPU Name Architecture Version Vendor
ensure precise, scalable fault analysis. PicoRV32 RV32IMC Master, 87c89ac YosysHQ
4 Implementation and Evaluation CVA6 RV64IMAC Master, 89986df OpenHW Group
We implement an automated verification pipeline, named RISC- VexRiscv RV32IM Master, b91c909 SpinalHDL
Rocket RV64IMAFDC Master, 8f1e33b CHIPS Alliance
Smith (about 30K+ lines of Rust code), which spans from instruction XiangShan RV64GC Master, 56fe218 OpenXiangShan
modeling to differential testing. RISCSmith uses the official RISC-V Kronos RV32IMC/RV32EC Master, b0c06eb lowRISC
UnifiedDB as its primary data source. Through automated parsing Compared Tools: We compared RISCSmith with two state-of-the-
and code generation, it constructs constrained and strongly typed art RISC-V CPU fuzzers: Cascade [34] and RISCV-DV [31]. Cascade
instruction models that serve as the basis for a random program gen- performs coverage-guided fuzzing on RTL models using Verilator
erator. The generator automatically prepares register and memory feedback to mutate instruction sequences, while RISCV-DV employs
contexts, models inter-instruction data dependencies, and includes an constrained-random generation within the SystemVerilog UVM frame-
exception propagation mechanism. To balance execution efficiency work to produce coverage-driven instruction streams. These two tools
and analytical precision, we integrate lightweight logging into the were chosen as baselines because they represent the most established
RTL and, during Verilator simulation, record per-instruction regis- approaches to RISC-V CPU fuzzing, Cascade emphasizing feedback-
ter updates, memory writes, and exceptions with minimal overhead. directed RTL fuzzing and RISCV-DV serving as the industry-standard
The framework conducts differential log analysis to locate the first random test generator.
behavioral divergence, identify register and memory mismatches, and Metrics and Settings: We employed three metrics for our evalua-
automatically generate minimized reproducing test cases, achieving tion: the number of unique bugs detected, the code coverage of target
a practical trade-off between large-scale validation and fine-grained CPUs, and the average speed-up to localize these bugs. These metrics
debugging. are commonly used to measure the effectiveness of fuzzers by prior
In this section, we evaluate RISCSmith to answer the following researches [4, 15, 34]. We ran each testing tool under the same envi-
three research questions: ronment setup on a computer equipped with an Intel(R) Core(TM)
• RQ1: Is RISCSmith effective in detecting vulnerabilities of real- i9-10900 CPU @ 2.80GHz, 32 GiB of DDR4 memory, and running world RISC-V CPUs? x86_64 Ubuntu Linux 20.04. All target RISC-V CPUs were tested using • RQ2: Can RISCSmith cover more code of RISC-V CPUs compared their default configuration parameters. All experiments were repeated with state-of-the-art methods? 10 times under identical conditions, and the average results are used • RQ3: Does the on-the-fly differential analyzer effectively improve in this paper. testing performance? 4.2 Bug Detection in Real-World RISC-V CPUs 4.1 Experiment setup We applied RISCSmith, Cascade, and RISCV-DV on all 6 target RISC- Subject: We evaluated RISCSmith on six real-world RISC-V CPUs V CPUs for real-world bug detection in 24 hours. In total, RISCSmith with diverse architectural configurations. Table 2 summarizes the de- discovered 18 previously unknown bugs across the six RISC-V CPUs, tailed information of these evaluation targets. The selection of CPUs significantly outperforming other state-of-the-art fuzzers, none of was based on two criteria: (1) They are widely deployed in practical which detected more than 5 bugs. Detailed information on these bugs environments, demonstrating RISCSmith’s ability to uncover bugs is summarized in Table 1. that could affect a broad spectrum of users; and (2) they represent As shown in Table 1, RISCSmith discovered 18 previously unknown bugs across six representative RISC-V CPUs. Among these bugs, six
RISCSmith: Finding RISC-V CPU Bugs via Rich Instruction Construction and On-the-fly Differential Analysis DAC ’26, July 26–29, 2026, Long Beach, CA, USA
1 // Simplified excerpt: reuse of rm[2] in the compare front-end
are related to exception or trap mis-encoding, which can cause the always_comb begin
2
processor to report incorrect exception causes or fail to trigger traps // Scalar compare: operation encoded in rm[1:0]
3
properly, potentially leading to silent system errors or security policy -- cmp_mode = rm[2:0]; 4 5 ++ cmp_mode = {1'b0, rm[1:0]}; // compare mode ignores rm[2] violations. Four bugs are found in floating-point units (FPU), including // AH encoding: reuse rm[2] to select FP16ALT format 6 incorrect handling of NaN boxing, faulty FP16/FP32 operand prop- if (!is_vector && check_ah) begin 7 agation, and sign-bit corruption in floating-point move operations, -- if (rm[2]) begin 8 9 ++ if (fp16alt_enable) begin which can produce inconsistent computation results or break IEEE- dst_format = FP16ALT; // treat operands as FP16ALT 10 754 compliance [27]. Three bugs involve CSR handling, where writes ... 11 12 to read-only performance counters or system registers (e.g., cycle, end instret, or time) were not trapped as illegal instructions–potentially Figure 4: A NaN-comparison bug caused by reusing rm[2] for allowing unauthorized modification of privileged states. In addition, both Zfa quiet compare and FP16ALT format selection. two bugs were detected in load/store units, leading to misaligned such as FP64; (2) enable both Zfa and FP16ALT and compare this access errors, stale register states, and corrupted data paths, while register with itself using fleq.; and (3) observe that the reference another two were found in AMO and memory logging units, revealing model (Spike) returns 0 (unordered) while CVA6, due to the rm[2] inconsistencies between hardware behavior and the reference model aliasing, returns 1 (equal), making this compare the first observable during atomic operations. Finally, one AXI-Lite interface defect caused divergence. Such NaN misclassification can silently corrupt control incorrect write strobes on misaligned stores. Overall, these findings flow in floating-point-intensive workloads. Figure 4 sketches the root demonstrate that RISCSmith effectively exposes diverse categories cause in the compare front-end. In the simplified excerpt, the original of logic flaws spanning exception encoding, floating-point computa- implementation derives the compare mode directly from all three bits tion, CSR privilege enforcement, and memory access behavior across of rm, while the most-significant bit rm[2] is also reused to select different RISC-V CPU architectures. FP16ALT via the AH-encoding logic: Comparison with existing Fuzzers: In our 24-hour experiments, In our experiments, this NaN-comparison defect was only detected Cascade and RISCV-DV identified only four and five bugs, respec- by RISCSmith. Existing RISC-V CPU fuzzers rely on manually main- tively. However, the remaining 14 bugs were hidden in less frequently tained instruction models and do not yet cover the Zfa fleq. in- tested but critical CPU instruction-handling logic, which was only structions, and they usually compare architectural state only at pro- exposed by RISCSmith’s rich instruction modeling, a capability ab- gram end, so mismatched comparison results are easily overwritten. sent in existing fuzzers. Unlike prior tools, RISCSmith automatically RISCSmith instead derives instruction models from the RISC-V Uni- constructs rich RISC-V instruction models from the official UnifiedDB, fiedDB and therefore supports Zfa fleq.d/fleq.s/fleq.h together enabling the generation of high-quality test programs that cover a with FP16ALT configurations; its lightweight logging records, for ev- wider range of CPU processing paths. Furthermore, through its on- ery instruction, the operands, result, and architectural writes, and the-fly, fine-grained differential analysis of memory and registers, a post-processing pass performs instruction-by-instruction differen- RISCSmith successfully uncovered all 18 bugs, demonstrating its ef- tial analysis against the reference model. As soon as a fleq.* result fectiveness and answering RQ1. Compared with other state-of-the-art disagrees with Spike, RISCSmith pinpoints that compare as the first CPU fuzzers, RISCSmith detected all the bugs found by them, while divergence and invokes automatic testcase minimization, reducing additionally revealing those hidden in complex instruction logic. the input to a short sequence that constructs the NaN and executes a Table 3: Bugs found by each fuzzing tools. Others detect no single fleq.. more than 5 bugs, while RISCSmith detects all 18 bugs. 4.3 Effectiveness in Code Coverage Tool Bug Number Bug IDs 1.0 Branch Coverage (%) (normalized) 1.0 Function Coverage (%) (normalized) RISCSmith 18 #1 – #18 0.8 0.8 Cascade 4 #2, #3, #9, #10 0.6 0.6 RISCV-DV 5 #2, #5, #9, #14, #16 0.4 0.4 0.2 0.2 4.2.1 Case Study. RISCSmith RISCSmith RISC-DV RISC-DV Cascade Cascade 0.0 0.0 0 500 1000 1500 2000 2500 3000 3500 0 500 1000 1500 2000 2500 3000 3500 We next present bug #11 from Table 1 as a case study illustrating Cumulative Time (s) Cumulative Time (s) how RISCSmith exposes semantic bugs in real RISC-V CPUs. As shown Figure 5: Code coverage over time. RISCSmith consistently cov- in Figure 4, a NaN-comparison defect in the CVA6 floating-point ers more branches and functions compared to SOTA tools. unit arises when the Zfa quiet-compare instructions (fleq.) are used Since different tools implement distinct coverage instrumentation together with the FP16ALT extension. The comparison front end mechanisms, we used the evaluation by leveraging their shared capa- reuses the rounding-mode bit rm[2] as both the Zfa "quiet compare" bility to collect coverage data from the RISC-V golden model Spike [30]. selector and the FP16ALT AH-format selector. For fleq., this reuse To fairly evaluate the effectiveness of RISCSmith in terms of code cov- can incorrectly force the comparison format to FP16ALT, causing a bit erage on RISC-V CPUs, we also adapted RISCSmith to Spike and used pattern that represents a quiet NaN in its true format (e.g., FP64) to be grcov [10] to collect coverage data over a 24-hour fuzzing period. The interpreted as a normal non-NaN value. As a result, fleq. returns 1 results, summarized in Figure 5, show that RISCSmith consistently instead of 0, where the RISC-V specification requires an unordered outperforms all other state-of-the-art tools in both branch and func- comparison. tion coverage. Compared with Cascade and RISCV-DV, RISCSmith This bug can be triggered by three conditions: (1) load a quiet- achieves a 37%?1% improvement in branch coverage and a 123%?34% NaN bit pattern into a scalar floating-point register in a wide format
Normalized
Normalized
DAC ’26, July 26–29, 2026, Long Beach, CA, USA Xudong Zhang†, Yuanliang Chen†B, Zehong Yu†, Zhen Yan†, Fuchen Ma†, Dalong Shi‡, Yu Jiang†B
improvement in function coverage. The main reason for this improve- instructions. However, many processors introduce various private or
ment is that RISCSmith supports a significantly broader and richer custom extensions to support domain-specific acceleration (e.g., AI,
set of RISC-V instruction models. As shown in Figure 6, the number DSP, cryptography) [7, 23, 28, 29, 32]. These extensions lack publicly
of instructions supported by RISCSmith is 2.3?.6x greater than that of available specification databases. In future work, we plan to extend
Cascade and RISCV-DV. This instruction modeling enables the genera- the RISCSmith parser and generator, thereby enabling support for
tion of more diverse and semantically complete test inputs, leading to such private and custom extensions and instructions.
higher code coverage across different CPU components. These results Extending the method to other domains. RISCSmith currently
provide a clear and comprehensive answer to RQ2. supports testing RISC-V CPUs, but its methodology can be extended
to other ISAs (e.g., ARM, x86) and architectures (e.g., GPUs) [2, 22, 33].
However, differences in ISA semantics and processor execution mod-
els make direct cross-domain migration technically challenging. To
address these issues, we plan to develop a more general instruction-
modeling workflow and cross-architecture logging and differential-
analysis tools to enable verification across heterogeneous architec-
tures [16, 36, 37].
Figure 6: Number of RISC-V instructions supported by RISC- 6 Related Work Smith and other SOTA tools. CPU Fuzzing. As one of the most complex hardware components, 4.4 Effectiveness in On-the-fly Analysis CPUs have inspired many specialized fuzzing techniques. DIFUZ- ZRTL [17] performs coverage-guided differential testing by align- To evaluate the effectiveness of RISCSmith’s on-the-fly differen- ing per-instruction states, while Cascade [34] generates long RISC-V tial analysis and assess the testing overhead introduced by its bug programs and reduces overhead via non-termination checks. The- localization process, we measured the average time each tool required Huzz [20] and INSTILLER [39] apply hardware-aware coverage met- to perform bug localization after detecting a difference, as summa- rics, and MorFuzz [38] improves semantic relevance through run- rized in Table 4. Since RISCV-DV lacks an automated bug localization time instruction morphing. However, these tools rely on manually component and only reports raw differences that require manual anal- built instruction models. In contrast, RISCSmith automatically derives ysis, it was excluded from the timing comparison. Compared with instruction models from the RISC-V UnifiedDB, ensuring semantic Cascade, which required an average of 5732.49 seconds for bug lo- correctness, preparing valid register and memory contexts for more calization, RISCSmith achieved an average analysis time of 3065.91 effective testing. seconds, representing a 46.5% improvement. Differential Testing. Differential testing has been widely applied Table 4: Average Bug localization time used by fuzzers. across many system domains. For example, DLFuzz [15] compares Cascade RISCV-DV RISCSmith the behaviors of different deep learning models to detect anomalies; Avg Bug Localization Time (ms) 5732.49 - 3065.91 DIFUZZRTL [17] contrasts CPU RTL execution with a reference sim- Improvement - - ↑46.5% ulator to find design flaws; Gandalf [26] checks operator outputs across deep learning libraries to uncover implementation bugs; and Table 5: Overhead Introduced by tools’ bug localization. CompDiff [24] compares binaries produced by different compilers Cascade RISCV-DV RISCSmith or optimization levels to reveal issues related to undefined behavior. Avg instruction execution (ms) 779.80 916.10 4080.19 In contrast, RISCSmith uses low-intrusion instrumentation to collect Avg analysis process (ms) 442.64 4126.44 630.92 RTL logs from different CPUs, capturing per-instruction register and Overhead (%) 56.76% 450.44% 15.46% memory writes and exception events with minimal overhead. This en- Improvement - - ↑72.8% ables efficient differential comparison while avoiding the inefficiency We also measured each tool’s average total instruction execution and potential missed detections of step-by-step pausing, allowing time during fuzzing, as well as the average time spent on differential RISCSmith to quickly find the instruction that triggers a divergence analysis, as summarized in Table 5. RISCSmith’s average instruction and automatically generate a minimized reproducing program. execution time was 4080.19 seconds, significantly higher than Cascade 7 Conclusion (779.8 s) and RISCV-DV (916.1 s), indicating that RISCSmith generates In this paper, we propose RISCSmith, which automatically mod- more complex instruction inputs capable of exercising deeper CPU els rich instructions and performs on-the-fly differential analysis for processing logic. Despite this, the average time RISCSmith spent on CPUs. We implemented RISCSmith and evaluated it on six widely differential analysis was much lower than that of RISCV-DV. The used RISC-V CPUs, discovering 18 new bugs and outperforming other overhead of RISCSmith’s on-the-fly differential analysis was only state-of-the-art tools in both bug detection and code coverage. 15.46%, substantially lower than that of both Cascade and RISCV-DV. These results provide a clear and comprehensive answer to RQ3. Acknowledgments 5 Discussion We would like to express our sincere gratitude to the anonymous Support for Private and Custom Extensions/Instructions. At reviewers for their valuable feedback and constructive comments on present, RISCSmith relies on the RISC-V UnifiedDB to construct in- this paper. This work was supported by the National Key Research struction models, and therefore only covers standard extensions and and Development Program of China under Grant 2024YFF1401303.
RISCSmith: Finding RISC-V CPU Bugs via Rich Instruction Construction and On-the-fly Differential Analysis DAC ’26, July 26–29, 2026, Long Beach, CA, USA
References [26] Jiawei Liu, Yuheng Huang, Zhijie Wang, Lei Ma, Chunrong Fang, Mingzheng Gu,
[1] Allon Adir, Shady Copty, Shimon Landa, Amir Nahir, Gil Shurek, Avi Ziv, Charles Xufan Zhang, and Zhenyu Chen. 2023. Generation-based differential fuzzing for
Meissner, and John Schumann. 2011. A unified methodology for pre-silicon verifica- deep learning libraries. ACM Transactions on Software Engineering and Methodology
tion and post-silicon validation. In 2011 Design, Automation & Test in Europe. IEEE, 33, 2 (2023), 1–28.
1–6. [27] Guillermo A Lopez, Michela Taufer, and Patricia J Teller. 2007. Evaluation of IEEE
[2] Muhammad Nabeel Asghar. 2020. A review of ARM processor architecture history, 754 floating-point arithmetic compliance across a wide range of heterogeneous
progress and applications. Journal of Applied and Emerging Sciences 10, 2 (2020), computers. In Proceedings of the 2007 conference on Diversity in computing. 1–4.
pp–171. [28] Karthik Parvathinathan, Maya Dewhurst, Victor Hayashi, and Joshua M Pearce. 2025.
[3] RISC-V BOOM. 2025. The Berkeley Out-of-Order RISCV Processor. https://github. Open-Source RISC-V Extension Design: Adding Custom Vector Instructions for DSP
com/riscv-boom/riscv-boom. Accessed at October 29, 2025. Workloads. (2025).
[4] Sadullah Canakci, Leila Delshadtehrani, Furkan Eris, Michael Bedford Taylor, Manuel [29] Cosmin-Andrei Popovici, Andrei Stan, Nicolae-Alexandru Botezatu, and Vasile-Ion
Egele, and Ajay Joshi. 2021. Directfuzz: Automated test generation for rtl designs Manta. 2025. RiscADA: RISC-V Extension for Optimized Control of External D/A
using directed graybox fuzzing. In 2021 58th ACM/IEEE Design Automation Conference and A/D Converters. Electronics 14, 15 (2025), 3152.
(DAC). IEEE, 529–534. [30] Spike risc-v isa simulator. 2025. RISC-V Software. https://github.com/riscv-software-
[5] Sadullah Canakci, Chathura Rajapaksha, Leila Delshadtehrani, Anoop Nataraja, src/riscv-isa-sim. Accessed at October 29, 2025.
Michael Bedford Taylor, Manuel Egele, and Ajay Joshi. 2023. ProcessorFuzz: [31] RISCV-DV. 2025. Random instruction generator for RISC-V processor verification.
Processor Fuzzing with Control and Status Registers Guidance. In 2023 IEEE In- https://github.com/chipsalliance/riscv-dv. Accessed at October 29, 2025.
ternational Symposium on Hardware Oriented Security and Trust (HOST). 1–12. [32] Muhammad Sabih, Abrarul Karim, Jakob Wittmann, Frank Hannig, and Jürgen Teich.
doi:10.1109/HOST55118.2023.10133714 2024. Hardware/software co-design of RISC-V extensions for accelerating sparse
[6] Jamison D Collins, Dean M Tullsen, Hong Wang, and John Paul Shen. 2001. Dynamic DNNs on FPGAs. In 2024 International Conference on Field Programmable Technology
speculative precomputation. In Proceedings. 34th ACM/IEEE International Symposium (ICFPT). IEEE, 01–09.
on Microarchitecture. MICRO-34. IEEE, 306–317. [33] Karthikeyan Sankaralingam, Jaikrishnan Menon, and Emily Blem. 2013. A detailed
[7] Enfang Cui, Tianzheng Li, and Qian Wei. 2023. Risc-v instruction set architecture analysis of contemporary arm and x86 architectures. Technical Report.
extensions: A survey. IEEE Access 11 (2023), 24696–24711. [34] Flavien Solt, Katharina Ceesay-Seitz, and Kaveh Razavi. 2024. Cascade:{CPU}
[8] Freddy Gabbay and Avi Mendelson. 1998. Using value prediction to increase the fuzzing via intricate program generation. In 33rd USENIX Security Symposium
power of speculative execution hardware. ACM Transactions on Computer Systems (USENIX Security 24). 5341–5358.
(TOCS) 16, 3 (1998), 234–270. [35] SonalPinto. 2025. Kronos is a 3-stage in-order RISC-V core towards FPGA imple-
[9] Rocket Chip Generator. 2025. CHIPS Alliance. https://github.com/chipsalliance/ mentations. https://github.com/SonalPinto/kronos. Accessed at October 29, 2025.
rocket-chip. Accessed at October 29, 2025. [36] Caroline Trippel, Yatin A Manerkar, Daniel Lustig, Michael Pellauer, and Margaret
[10] GRCOV. 2025. Rust tool to collect and aggregate code coverage data for multiple Martonosi. 2017. TriCheck: Memory model verification at the trisection of software,
source files. https://github.com/mozilla/grcov. Accessed at October 29, 2025. hardware, and ISA. ACM SIGPLAN Notices 52, 4 (2017), 119–133.
[11] OpenHW Group. 2025. CVA6 RISC-V CPU. https://github.com/openhwgroup/cva6/. [37] Xiaoguang Wang, SengMing Yeoh, Robert Lyerly, Pierre Olivier, Sang-Hoon Kim,
Accessed at October 29, 2025. and Binoy Ravindran. 2020. A framework for software diversification with {ISA}
[12] OpenXiangShan Group. 2025. Open-source high-performance RISC-V processor. heterogeneity. In 23rd International Symposium on Research in Attacks, Intrusions
https://github.com/OpenXiangShan/XiangShan. Accessed at October 29, 2025. and Defenses (RAID 2020). 427–442.
[13] SpinalHDL Group. 2025. A FPGA friendly 32 bit RISC-V CPU implementation. [38] Jinyan Xu, Yiyuan Liu, Sirui He, Haoran Lin, Yajin Zhou, and Cong Wang. 2023. https://github.com/SpinalHDL/VexRiscv. Accessed at October 29, 2025. {MorFuzz}: Fuzzing processor via runtime instruction morphing enhanced synchro- [14] YosysHQ Group. 2025. PicoRV32 - A Size-Optimized RISC-V CPU. https://github. nizable co-simulation. In 32nd USENIX Security Symposium (USENIX Security 23). com/YosysHQ/picorv32. Accessed at October 29, 2025. 1307–1324. [15] Jianmin Guo, Yu Jiang, Yue Zhao, Quan Chen, and Jiaguang Sun. 2018. Dlfuzz: [39] Gen Zhang, Pengfei Wang, Tai Yue, Danjun Liu, Yubei Guo, and Kai Lu. 2024. IN- Differential fuzzing testing of deep learning systems. In Proceedings of the 2018 26th STILLER: Toward efficient and realistic RTL fuzzing. IEEE Transactions on Computer- ACM Joint Meeting on European Software Engineering Conference and Symposium on Aided Design of Integrated Circuits and Systems 43, 7 (2024), 2177–2190. the Foundations of Software Engineering. 739–743. [40] Wendi Zhang, Yonghui Zhang, and Kun Zhao. 2021. Design and verification of [16] Bo-Yuan Huang, Hongce Zhang, Pramod Subramanyan, Yakir Vizel, Aarti Gupta, three-stage pipeline cpu based on risc-v architecture. In 2021 5th Asian Conference and Sharad Malik. 2018. Instruction-level abstraction (ila) a uniform specification on Artificial Intelligence Technology (ACAIT). IEEE, 697–703. for system-on-chip (soc) verification. ACM Transactions on Design Automation of Electronic Systems (TODAES) 24, 1 (2018), 1–24. [17] Jaewon Hur, Suhwan Song, Dongup Kwon, Eunjin Baek, Jangwoo Kim, and By- oungyoung Lee. 2021. Difuzzrtl: Differential fuzz testing to find cpu bugs. In 2021 IEEE Symposium on Security and Privacy (SP). IEEE, 1286–1303. [18] Intel. 1994. Intel Annual Report. https://www.intel.com/content/www/us/en/history/ history-1994-annual-report.html. [19] Saad Islam, Ahmad Moghimi, Ida Bruhns, Moritz Krebbel, Berk Gulmezoglu, Thomas Eisenbarth, and Berk Sunar. 2019. SPOILER: speculative load hazards boost rowham- mer and cache attacks. In Proceedings of the 28th USENIX Conference on Security Symposium (Santa Clara, CA, USA) (SEC’19). USENIX Association, USA, 621–637. [20] Rahul Kande, Addison Crump, Garrett Persyn, Patrick Jauernig, Ahmad-Reza Sadeghi, Aakash Tyagi, and Jeyavijayan Rajendran. 2022. {TheHuzz}: Instruction fuzzing of processors using {Golden-Reference} models for finding {Software-Exploitable} vulnerabilities. In 31st USENIX Security Symposium (USENIX Security 22). 3219–3236. [21] Paul Kocher, Jann Horn, Anders Fogh, Daniel Genkin, Daniel Gruss, Werner Haas, Mike Hamburg, Moritz Lipp, Stefan Mangard, Thomas Prescher, Michael Schwarz, and Yuval Yarom. 2019. Spectre Attacks: Exploiting Speculative Execution. In 2019 IEEE Symposium on Security and Privacy (SP). 1–19. doi:10.1109/SP.2019.00002 [22] Christos Kyrkou. 2009. Stream processors and GPUs: Architectures for high per- formance computing. Survey on Stream Processor and Graphics Processing Units (2009). [23] Huimin Li, Nele Mentens, and Stjepan Picek. 2023. Maximizing the potential of custom RISC-V vector extensions for speeding up SHA-3 Hash functions. In 2023 Design, Automation & Test in Europe Conference & Exhibition (DATE). IEEE, 1–6. [24] Shaohua Li and Zhendong Su. 2023. Finding unstable code via compiler-driven differential testing. In Proceedings of the 28th ACM International Conference on Ar- chitectural Support for Programming Languages and Operating Systems, Volume 3. 238–251. [25] Moritz Lipp, Michael Schwarz, Daniel Gruss, Thomas Prescher, Werner Haas, Jann Horn, Stefan Mangard, Paul Kocher, Daniel Genkin, Yuval Yarom, Mike Hamburg, and Raoul Strackx. 2020. Meltdown: reading kernel memory from user space. Commun. ACM 63, 6 (May 2020), 46–56. doi:10.1145/3357033