A Fuzzing Model Built Around the Hardware
FuzzGPU answers the title's question by treating the GPU's execution contract as part of the testing instrument. This final synthesis connects the SIMT-aware generator, the differential oracle, the reported measurements, the RISC-V context, and the discovered failure classes into a single judgment. It gives readers a practical test for any proposed GPU-fuzzing approach: does it model the target deeply enough on both sides of the experiment, and does it state clearly what its evidence still cannot establish?
The model must sit on both sides of the experiment
A conventional description of fuzzing separates inputs from checking. The generator creates stress; an oracle decides whether the result is wrong. FuzzGPU shows why that separation is misleading for GPU hardware. The target's execution model constrains the generator because a program must preserve thread masks, reconvergence, barrier scopes, and legal memory accesses to run deeply. The same model constrains the oracle because writeback order, synchronization, and memory visibility determine which observations are architectural, transient, or legally variable.
The two sides form a chain of evidence rather than two independent tools. A test first has to reach the state that matters. The generation stack makes divergent paths reachable without treating every path as an independent scalar program. The barrier planner makes synchronization rich without generating circular waits under its modeled scopes. Interleaved warp generation creates cross-thread memory relationships while taint records where a result may not have a single deterministic explanation.
Only then does observability become useful. Instruction IDs and per-warp completion queues map out-of-order physical writebacks back to a meaningful per-warp order. Barrier-aware scheduling stops the reference model from crossing a collective synchronization point merely because one queue is ready. Tainted memory events move to an axiomatic validator that asks whether the observed reads, writes, and ordering relations are permitted, rather than forcing them to match one arbitrary serialization.
Correctness comes after those two forms of preparation. A mismatch that appears before fair ordering and memory rules are applied is a symptom, not a diagnosis. A mismatch that survives them can be localized to an instruction, thread mask, register, address, or microarchitectural event. That is why the model's parts cannot be evaluated as interchangeable features. A faster generator that produces shallow or stalled programs does not compensate for an oracle that creates false positives. A precise oracle does not compensate for tests that never reach the states it can inspect.
This relationship also clarifies the meaning of validity. Validity is not merely the absence of an illegal encoding. It is the preservation of enough execution structure that generated complexity becomes executed behavior. On a GPU, that means a divergent path must reconverge, participating warps must encounter barriers in a compatible order, and memory interactions must remain legal while still being interesting. Each condition converts nominal program length into useful exposure of the hardware.
Observability is not the same as determinism. A test can complete while a load has several legal sources or while physical writeback events arrive in an order that differs from the reference model's construction order. FuzzGPU preserves those observations, marks the uncertainty, and chooses a rule suited to the question. This is a more honest form of differential testing than declaring every unexpected value to be wrong, because it distinguishes an incomplete model from a defective implementation.
The paper's bug results illustrate the payoff of this chain. The reported 20 previously unknown bugs span 17 RTL defects and three ISS defects, with ten CVE identifiers assigned. They include memory-address calculation, inactive-thread writeback, register and operand corruption, arithmetic errors, tensor-operation state corruption, instruction-cache or writeback hangs, scoreboard behavior, and simulator discrepancies.