Skip to content
STIMSMITH

Bug Oracle

Concept

A bug oracle is a program, check, or rule used during dynamic verification (most notably fuzzing) to decide whether a given test input causes the program under test (PUT) to violate a correctness policy and thereby expose a bug. Bug oracles range in sophistication from simple exit-code checks, through instrumented memory- and control-flow checks, to differential comparisons against a reference model or even human-in-the-loop judgements.

First seen 6/19/2026
Last seen 6/19/2026
Evidence 1 chunks
Wiki v1

WIKI

Definition

In the fuzzing literature, a bug oracle is a program that determines whether a test case has broken a correctness policy of the program under test (PUT). The policy need not correspond to a software defect in the traditional sense — it can also express other correctness concerns such as performance problems or resource-use violations. The oracle is typically consumed by the InputEval step of a fuzzing loop, which takes the current configuration, a generated test case, and the bug oracle, and produces execution information that may include a detected bug.

Role in a fuzzing loop

READ FULL ARTICLE →

NEIGHBORHOOD

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

explore full graph →

RELATIONSHIPS

1 connections
differential testing ← uses 93% 1e
Differential testing uses a bug oracle by comparing outputs of two implementations.

CITATIONS

8 sources
8 citations — click to expand
[1] A bug oracle is a program that determines if a test case has broken a correctness policy of the program under test, and this policy need not be a bug — it can also include concerns such as performance problems. Fuzzing IPv4 modules on FPGAs
[2] Bug oracles are consumed by the InputEval stage of a fuzzing loop, together with the configuration and test case, producing execution information and potentially a detected bug. Fuzzing IPv4 modules on FPGAs
[3] The original exit-code-based bug oracle checks the exit code of a program to determine if a bug was found (e.g. fatal signal), but is limited to major bugs and cannot detect minor ones such as stack buffer overflows. Fuzzing IPv4 modules on FPGAs
[4] To expose minor bugs, transformations of the program can be performed, including spatial and temporal memory checks, illegal control flow, and undefined-behaviour checks for languages such as C. Fuzzing IPv4 modules on FPGAs
[5] To find semantic bugs, bug oracles typically rely on differential testing, comparing the behaviour of the PUT against a reference model or another similar program; divergent outputs are taken to indicate a likely bug. Fuzzing IPv4 modules on FPGAs
[6] FirmReBugger expresses bug oracles as C-syntax expressions of bug descriptors, evaluates them with an interpreter, and discriminates between the states not reached, reached, triggered, and detected. FirmReBugger: A Benchmark Framework for Monolithic Firmware Fuzzers
[7] FirmReBugger's FirmBench ships with 313 software bug oracles used to benchmark monolithic firmware fuzzers. FirmReBugger: A Benchmark Framework for Monolithic Firmware Fuzzers
[8] When no automated bug oracle exists, the user reporting the bug can act as the oracle; Learn2fix trains an automatic bug oracle by querying the user about whether alternative test inputs exhibit the bug. Human-In-The-Loop Automatic Program Repair