From Mismatched Traces to Security Bugs
FuzzGPU's reported mismatches are not the end of an experiment; they are the beginning of diagnosis. This chapter follows how the framework's execution-aware generator and oracle turn a suspicious trace into a classified RTL defect, ISS defect, legal variation, or unresolved case, then asks what security consequences can reasonably follow. The distinction matters because the same visible symptom—a value that differs from a reference—can represent a memory-model choice, a simulator mistake, a hardware error, or a conditional risk under a particular deployment.
A mismatch is a starting point, not a diagnosis
A differential tester is designed to make disagreement visible, but visibility alone does not identify the cause. FuzzGPU compares instruction-level traces and uses memory-consistency rules for ambiguous operations. When the checker reports a difference, the first question is whether the execution was compared fairly. Was the writeback associated with the correct instruction? Did the reference model step across a barrier too early? Was the load tainted because several stores could legally supply its value? A difference that disappears after those questions are answered is not an RTL bug.
This filtering step is what makes the GPU-specific oracle important to bug analysis. Instruction IDs and per-warp completion queues prevent out-of-order physical writeback from being mistaken for architectural disorder. Barrier-aware scheduling prevents a reference-model timing artifact from being blamed on the DUT. Taint and the memory validator prevent a legal read-from choice from turning into a cascade of false mismatches in dependent registers and branches. Only after those explanations have been considered does a persistent difference become a candidate defect.
The next step is to reproduce and localize the candidate. An instruction-level trace contains more than a final wrong answer. It identifies the program counter, active thread mask, destination register, and written value associated with an event. That context helps answer whether the problem appeared for all threads or only an active subset, whether it arose after divergence or a barrier, and whether a later operation merely exposed an earlier corruption. A final architectural state may hide the first failure if another instruction overwrites the damaged value.
The paper's 20 discoveries show why classification must remain broad. Fourteen were in OpenGPGPU, three in Vortex, and three in the simulators. The paper reports 17 RTL bugs and three ISS bugs overall, with ten assigned CVE identifiers. These categories should not be merged. An ISS can misimplement an instruction-set rule and falsely accuse correct hardware, while an RTL defect can make the hardware disagree with an otherwise correct ISS. The remediation path, security impact, and evidence needed for each are different.
The failure surfaces are different
Memory-address and memory-operation defects concern where an access goes or what operation it performs. One OpenGPGPU finding involved incorrect private-memory address calculation when fewer active threads were present than the hardware capacity. The resulting out-of-bounds access is a hardware behavior problem, not merely an unexpected value in a reference trace. Other findings involved incorrect atomic results and vector load/store behavior that ignored a field-count parameter. These defects connect directly to the interaction between active masks, address calculation, and the memory system.
Register and operand defects concern which state a result changes or which source an instruction reads. The study found a Vortex issue in which floating-point results could be written into integer registers sharing an index when register-extension prefixes were used. It also found a vector comparison operand-fetch error in which the hardware read a vector register instead of the specified scalar register.