Skip to content
STIMSMITH

Fuzzing

Technique

Fuzzing, in the provided ARM-simulator testing artifact, is an AFL++-based technique that runs an instrumented gem5 ARM simulator against inputs from prepared seed corpora, uses SearchSYS custom mutators in custom-mutator-only mode, records queue/crash/hang outputs and fuzzer_stats, and then supports differential testing of fuzzed queue seeds against native execution.

First seen 6/4/2026
Last seen 8/12/2026
Evidence 60 chunks
Wiki v3

WIKI

Fuzzing

Definition in this artifact

In the Search+LLM-based ARM simulator testing artifact, fuzzing is implemented as an AFL++ workflow over an instrumented ARM build of gem5. The fuzzer is run with an input corpus, an output directory for fuzzed results, and three SearchSYS custom mutator libraries: cm-gem5c.so, cm-gem5c-bin.so, and cm-gem5c-types.so [C1].

READ FULL ARTICLE →

NEIGHBORHOOD

No graph connections found for this entity yet. It may appear in future ingestion runs.

explore full graph →

RELATIONSHIPS

36 connections
SearchSYS ← implements 100% 4e
SearchSYS implements fuzzing as one of its testing strategies.
The paper compares symbolic execution to fuzzing, noting that fuzzing is susceptible to missing corner-case bugs.
seed generation uses → 100% 2e
Fuzzing relies on seed inputs to start the mutation process.
test-case uses → 100% 2e
Fuzzing uses synthetically generated test-cases to stress-test the CPU emulator.
The paper uses fuzzing as one of the core testing techniques.
seed corpus uses → 100% 2e
Fuzzing uses the LLM-generated seed corpus as initial inputs.
Custom Mutator uses → 100% 2e
Fuzzing with AFL++ uses custom mutators tailored for gem5.
Testing CPU Emulators ← uses 100% 2e
The paper presents a testing methodology based on fuzzing for CPU emulators.
Fuzz4All ← uses 93% 2e
Fuzz4All is a fuzzing tool that uses LLMs for input generation.
TitanFuzz ← uses 96% 2e
TitanFuzz uses LLMs to generate and mutate human-like code for fuzzing deep learning libraries.
Coverage-Guided Fuzzing ← implements 95% 1e
Coverage-guided fuzzing is a specific type of fuzzing technique.
ProcessorFuzz ← implements 100% 1e
ProcessorFuzz implements fuzzing for processor testing.
SIGFuzz ← implements 100% 1e
SIGFuzz implements fuzzing to discover timing side channels.
mutation engine uses → 100% 1e
Fuzzing uses a mutation engine to generate mutated inputs.
Coverage Feedback uses → 95% 1e
Fuzzing uses coverage feedback to guide input generation.
LKL-fuzzer ← uses 97% 1e
LKL-fuzzer is a kernel fuzzing technique that generates eBPF programs to find correctness bugs.
BRF ← uses 97% 1e
BRF is a kernel fuzzing technique that generates eBPF programs passing the verifier to find correctness bugs.
BVF ← uses 97% 1e
BVF is a kernel fuzzing technique that generates eBPF programs passing the verifier to find correctness bugs.
WADIFF ← uses 93% 1e
WADIFF generated test cases for each Wasm operator and then fuzzed them.
Wasmaker ← uses 88% 1e
Wasmaker performs similar fuzzing to WADIFF but generates more complex binaries.
ChatFuzz ← uses 90% 1e
ChatFuzz is a fuzzing tool that leverages LLMs to improve fuzz testing.
OSS-Fuzz ← implements 100% 1e
OSS-Fuzz implements continuous fuzzing for open source software.
Vulnerability Discovery ← part of 100% 1e
Fuzzing has become a powerful technique for vulnerability discovery.
Experiment-ARM-24h.sh ← implements 100% 1e
Experiment-ARM-24h.sh runs the 24-hour fuzzing campaigns for each corpus.
sandsifter ← implements 90% 1e
Sandsifter uses depth-first-search-based fuzzing to determine x86 instruction lengths.
hardware fuzzing ← extends 90% 1e
Hardware fuzzing is an adaptation of software fuzzing techniques applied to hardware verification.
UISFuzz ← implements 90% 1e
UISFuzz is a hardware fuzzing method for CPU undocumented instruction searching.
Test Case Quality implements → 80% 1e
Fuzzing is used to improve test case quality in verification contexts.
Processor Verification implements → 95% 1e
Fuzzing is an advanced software testing technique applied to processor verification.
simulation-based verification ← uses 95% 1e
Simulation-based approaches incorporate fuzzing to improve coverage.
Coverage-guided Fuzzing ← derived from 90% 1e
Coverage-guided fuzzing is a modern form of fuzzing that uses coverage to guide mutation.
Symbolic Execution compares with → 90% 1e
Symbolic execution is contrasted with fuzzing, noted as a formal technique that can explore large state spaces more efficiently.
Cascade ← uses 95% 1e
The repository is described as hosting fuzzing code for Cascade.
The paper mentions fuzzing as a related technique for RISC-V verification.
TestRIG ← implements 90% 1e
TestRIG includes a single-implementation mode that enables more traditional fuzzing.
hardware fuzzing ← derived from 78% 1e
Positions hardware fuzzing as an approach that builds on principles established by (software) fuzzing.

CITATIONS

9 sources
9 citations — click to expand
[1] AFL++ fuzzing is configured with SearchSYS custom mutator libraries, corpus input/output directories, gem5 as target, and ARM workload invocation. Artifact of Search+LLM-based Testing for ARM Simulators - Zenodo
[2] The fuzzing run uses custom-mutator-only mode, and standard AFL mutation stages are disabled in that mode. Artifact of Search+LLM-based Testing for ARM Simulators - Zenodo
[3] The artifact builds AFL++ and then builds an ARM gem5 target with AFL++ compiler-wrapper instrumentation. Artifact of Search+LLM-based Testing for ARM Simulators - Zenodo
[4] Model-specific corpus preparation compiles C programs, copies binaries into cmin corpus directories, and rewrites input paths for models including Magicoder, TinyLlama, Phi, gpt3.5-new, and gpt3.5-old. Artifact of Search+LLM-based Testing for ARM Simulators - Zenodo
[5] Full fuzzing results are produced with Experiment-ARM-24h.sh over multiple initial corpora and repeats, and each script run lasts 24 hours per repeat and input corpus. Artifact of Search+LLM-based Testing for ARM Simulators - Zenodo
[6] AFL++ reports successful loading and installation of custom mutator libraries by finding afl_custom_mutator and afl_custom_fuzz_count. Artifact of Search+LLM-based Testing for ARM Simulators - Zenodo
[7] Run analysis examines queue, crash, and hang folders, with additional statistics in fuzzer_stats, and fuzzing randomness can cause slight differences between repeats. Artifact of Search+LLM-based Testing for ARM Simulators - Zenodo
[8] Differential testing is applied to fuzzed queue outputs and bug identification is manual and requires a system simulator expert. Artifact of Search+LLM-based Testing for ARM Simulators - Zenodo
[9] An example differential comparison shows matching gem5 and native outputs, so no bug is exposed in that case. Artifact of Search+LLM-based Testing for ARM Simulators - Zenodo