Bug Injection
ConceptBug injection is the practice of deliberately introducing synthetic faults into real programs or hardware designs to evaluate bug-finding tools such as fuzzers. In software fuzzing, large-scale studies have shown that injected bugs are easier to discover than organic ones, raising questions about how faithfully they model real defects. In hardware research, empirical surveys have shown that most natural CPU bugs reduce to two syntactic transformation classes—signal mix-ups and broken conditionals—which automated frameworks such as ENCARSIA use to inject realistic, architecturally observable bugs into RTL designs for systematic fuzzer evaluation.
First seen 7/4/2026
Last seen 7/15/2026
Evidence 14 chunks
Wiki v2
WIKI
Overview
Bug injection is the practice of deliberately inserting synthetic bugs into real programs or hardware designs in order to evaluate and compare bug-finding tools, most notably fuzzers. Because organic bugs in mature code bases are scarce and hard to collect at scale, injected bugs serve as a controlled, repeatable ground truth for measuring how effectively a fuzzer can explore a design and surface real defects [arxiv:2208.11088]. The technique is used in both software-fuzzing research (e.g., the Rode0day bug-finding competition and the LAVA-M corpus) and in hardware-fuzzing research on RTL CPU designs [ENCARSIA:sec25].
Software Bug Injection
NEIGHBORHOOD
No graph connections found for this entity yet. It may appear in future ingestion runs.
explore full graph →RELATIONSHIPS
4 connectionsBroken conditionals are one of two categories of bugs that ENCARSIA injects.
Signal mix-ups are one of two categories of bugs that ENCARSIA injects.
ENCARSIA implements automatic bug injection into RTL designs.
Bug injection is used to evaluate coverage-guided hardware fuzzers
LINKED ENTITIES
1 linksCITATIONS
18 sources18 citations — click to expand
[1] Bug injection adds synthetic bugs into real programs to act as proxies for organic defects because organic bugs in mature code bases are scarce and hard to collect at scale. Evaluating Synthetic Bugs
[2] Synthetic and organic bugs live in dramatically different parts of the program with respect to the 'main path' explored by a fuzzer, so fuzzer effectiveness on synthetic corpora does not necessarily transfer to real bugs. Evaluating Synthetic Bugs
[3] In a study of 8 fuzzers across 20 targets (Rode0day, LAVA-M), no fuzzer found any of the 50 available organic CVEs in the corpus even though all could be triggered, while the same fuzzers could discover many of the injected bugs. Evaluating Synthetic Bugs
[4] Bug injection has been used to introduce deliberate faults into code samples to assess how consistently ChatGPT can propose correct fixes across temperature settings. Analyzing the Instability of Large Language Models in Automated Bug Injection and Correction
[5] Historically, hardware researchers relied on manual bug insertion in two contexts: ad-hoc demo bugs (≤ 7 hand-crafted bugs per design) and competition bugs for events such as HACK@DAC, performed almost exclusively on CVA6 with designs not disclosed publicly. Encarsia: Evaluating CPU Fuzzers via Automatic Bug Injection
[6] ENCARSIA is grounded in a survey of 177 software-observable bugs across four open-source RISC-V CPUs (Ibex, CVA6, Rocket, BOOM) and the bugs collapse into two syntactic transformation classes: signal mix-ups and broken conditionals. Encarsia: Evaluating CPU Fuzzers via Automatic Bug Injection
[7] Ibex PR #399 is an example signal mix-up in which a designer used the partial result `illegal_csr_insn_o` instead of the final result `illegal_csr_priv` in a CSR-write enable expression, allowing unauthorized access to debug CSRs. Encarsia: Evaluating CPU Fuzzers via Automatic Bug Injection
[8] In Yosys's IR, assignments are pairs of wires with driver signals; ENCARSIA injects signal mix-ups by replacing the driver signal (RHS) with another random signal in the same RTL module, sign-extending constants that are smaller than the driven wire to match Verilog semantics. Encarsia: Evaluating CPU Fuzzers via Automatic Bug Injection
[9] For logical expressions, ENCARSIA inserts an intermediate wire between each cell port and its connected signal so that injecting a mix-up at the intermediate wire is equivalent to injecting one at the cell port, with the intermediate wires later cleaned up by an optimisation pass. Encarsia: Evaluating CPU Fuzzers via Automatic Bug Injection
[10] Yosys represents conditionals as multiplexer trees; ENCARSIA abstracts each tree into a table mapping select-signal combinations to chosen expressions, constructed by depth-first search from multiplexer roots (wires driven by a multiplexer that do not drive another multiplexer). Encarsia: Evaluating CPU Fuzzers via Automatic Bug Injection
[11] Table transformations include removing a row (forgetting a special case), turning a select signal into a don't-care (insufficient constraints), and turning a don't-care select into a specific value (constraints placed mistakenly); these cover the entirety of conditional-logic bugs in the survey. Encarsia: Evaluating CPU Fuzzers via Automatic Bug Injection
[12] After manipulation, tables are translated back to circuitry by emitting a Yosys internal `pmux` cell with one-hot select encoding, with `eq` cells comparing each row's stored select combination against the actual select value, and the Yosys backend converts the `pmux` cell back into a process resembling the original conditional statement. Encarsia: Evaluating CPU Fuzzers via Automatic Bug Injection
[13] Miter circuits and SystemVerilog Assertions are used to certify that each transformation produces an architecturally observable deviation; e.g., triple-modular-redundancy voters corrupted to select the minority value would be undetectable by current CPU fuzzers because they do not model single-event upsets. Encarsia: Evaluating CPU Fuzzers via Automatic Bug Injection
[14] Formal verification constrains the setup to resemble fuzzer initialisation: CPUs are reset, control/status registers are configured (e.g., FS of mstatus set to 1), and SVA `assume` statements restrict input behaviour (e.g., a single hardware thread on Ibex); Jasper is then asked to cover the `c_propagated` property. Encarsia: Evaluating CPU Fuzzers via Automatic Bug Injection
[15] ENCARSIA's transformation step takes on average less than a second per transformation even for BOOM; across Ibex/Rocket/BOOM it injected 1210/931/1230 mix-ups (avg. 213/134/886 ms) and 1111/718/982 conditionals (avg. 88/65/407 ms), and injected 3371 mix-ups across 121 modules and 2811 conditionals across 37 modules. Encarsia: Evaluating CPU Fuzzers via Automatic Bug Injection
[16] Verification (with Jasper) has much lower success: across Ibex/Rocket/BOOM, mix-ups succeed at 45%/44%/24% (avg. 211/194/258 s) and conditionals at 4.5%/8.1%/2.3% (avg. 116/117/195 s). Encarsia: Evaluating CPU Fuzzers via Automatic Bug Injection
[17] ENCARSIA produced EnCorpus, a unified corpus of 90 bugs for evaluating hardware fuzzers, and was evaluated against DifuzzRTL, ProcessFuzz, and Cascade, with each finding roughly 40–42 % of injected bugs within 24 hours on Ibex, Rocket, and BOOM. Encarsia: Evaluating CPU Fuzzers via Automatic Bug Injection
[18] Cascade's per-bug detection table on Ibex shows it detected only bugs 1, 4, and 5 among 15 mix-ups/conditionals (the rest not detected), illustrating the gap left by black-box CPU fuzzing. Encarsia: Evaluating CPU Fuzzers via Automatic Bug Injection