A GPU Is Not a CPU with More Threads
FuzzGPU is a framework for finding bugs in GPU hardware designs, and its study on the open-source Vortex and OpenGPGPU GPUs asks a deceptively simple question: what must a fuzzer understand before its test results can be trusted? The answer is not just the instruction set, or the number of threads a processor can run. It is the GPU's execution model—the way threads diverge, synchronize, share memory, and complete work at different times. Understanding that distinction gives readers a practical way to judge both the depth of a GPU test and the credibility of a reported mismatch.
Hardware errors outlast software assumptions
GPUs have become essential to systems that train artificial-intelligence models, run scientific simulations, and support many other demanding workloads. Their growing performance has come with growing microarchitectural complexity. More scheduling, memory, and execution machinery creates more places where an implementation can behave differently from its specification.
That difference matters more in hardware than it does in an ordinary software release. A software defect can often be corrected by replacing a library or shipping a patch. Once a circuit has been manufactured, its behavior is much harder to change. The paper therefore treats a hardware bug as a persistent break in the contract on which software depends. A program can be correct according to an architectural model and still produce an unsafe or incorrect result when the physical implementation violates that model.
FuzzGPU addresses this gap at the Register Transfer Level, or RTL: the description of digital hardware in terms of registers, data movement, and control logic before it becomes a finished chip. The authors evaluate the framework on Vortex and OpenGPGPU, two open-source GPU designs that make RTL validation possible. In the paper's stated scope, FuzzGPU is the first framework to combine a generator designed for GPU-style Single-Instruction, Multiple-Thread (SIMT) execution with a GPU-specific differential-testing harness.
The result is substantial but should be read precisely. Across the evaluated designs and simulators, the study reports 20 previously unknown bugs: 17 in RTL and three in instruction-set simulators (ISSs), with 10 assigned CVE identifiers. That is evidence that the method can expose defects ordinary regression testing did not reveal. It is not a count of every weakness in either GPU, nor a claim that all commercial GPUs would respond the same way. The important point is the connection between method and discovery: a fuzzer found these bugs because it was built to exercise behaviors that a CPU-oriented approach was likely to miss and to interpret the resulting traces without assuming that every difference was an error.
Why a GPU changes the fuzzing problem
Hardware fuzzing usually follows a useful pattern. Generate a large number of inputs, run them through a device under test, and compare the results with some oracle—a rule, assertion, or reference implementation that says what should happen. On a simple sequential processor, a random but legal instruction stream may be enough to reach a broad range of states. On a GPU, legality is only the beginning.
A GPU program is a hierarchy of cooperating work. A host launches a grid of cooperative thread arrays; each array contains warps; each warp carries out a common instruction stream across multiple threads. A thread has its own register context and an active predicate mask. When a branch sends different threads along different paths, the warp does not become a collection of independent CPUs. It records which threads are active on each path and later reconverges them. A synchronization barrier adds another dependency: a warp may need to wait until other participating warps reach the matching point.
Those rules make a flat stream of valid instructions a poor description of a valid GPU test. A program can be correctly encoded and still abandon most of its instructions because its threads diverge in a way the generator did not model. It can stop at a barrier because different warps arrive at incompatible points. It can run far enough to produce an output that differs from a reference model for a legal reason, such as the timing of a cross-thread memory operation.
Consider what a single conditional branch means in this setting. If some threads take the branch and others do not, the machine must remember both the active mask and the point at which the paths can join. The instructions on the less-populated path are not simply optional work: they may update registers, touch memory, or determine when a later barrier can be reached. If the test generator emits one path without preserving the reconvergence relationship, it may create dead code or leave part of the warp permanently inactive. If it places a barrier without coordinating the other warps that share its scope, the test can wait forever. The difficulty is therefore structural. The generator has to make a program complicated in ways the target can execute, not complicated in ways that merely enlarge the instruction stream.
The paper measured this problem by adapting two state-of-the-art CPU fuzzers, Cascade and DiveFuzz, to GPU instruction sets. In multi-thread and multi-warp tests, their programs often aborted early. When the same generators were restricted to one thread or one warp, their median completion rates recovered to 99% and 98%, respectively. The contrast points to concurrency as the central obstacle, not simply unfamiliar instruction encodings. In another analysis, 79% of Cascade's rejected tests were attributed to invalid control flow caused by multithreaded nondeterminism. For DiveFuzz, 61% of rejections involved SIMT-stack or warp-level matrix-operation errors, while 4% involved barriers.
These rejected tests are not automatically hardware bugs. Some behaviors are permitted by the target's instruction-set rules; they are simply unhelpful for a campaign whose purpose is to exercise deep hardware state. A test that stops after a few instructions cannot explore the interactions among caches, scoreboards, register banks, memory units, and control logic that make a GPU difficult to verify. It also leaves the checker with too little execution history to localize a later discrepancy. The generator must therefore understand enough of SIMT execution to keep complicated tests alive while retaining the relationships that make their behavior interpretable.
The oracle faces a different problem. GPU cores may issue instructions in an orderly way within a warp but write results back out of order to hide latency. They may not provide the same reorder-buffer and precise-commit behavior that makes a CPU's architectural state easy to identify. A register value observed in the middle of execution can be transient rather than the value that the program has architecturally committed.
Memory makes the comparison harder still. Imagine one warp reading an address while other warps store different values there, without a synchronization operation that fixes their visibility order. The hardware may legally return the old value or one of the stores, depending on propagation and arbitration timing. An ISA-level reference model that serializes those stores in one convenient order will produce one answer, but that answer is not necessarily the only correct one. Treating every difference as a defect would make the oracle punish the implementation for following a legal execution.
That is why the reference model must know when its answer is definitive and when it is only one permitted possibility. The checker needs enough information to compare ordinary operations precisely, while sending timing-dependent memory cases to a rule set that can recognize several legal outcomes. Without that distinction, more aggressive input generation would simply create more false alarms.
So the central distinction is two-sided. A GPU fuzzer must understand how to produce a test that follows the target's execution rules, and it must understand how to interpret an execution whose timing and ordering are not fully determined by an ISA-level model. Solving only the first problem creates deep but noisy experiments. Solving only the second creates a careful checker with little useful behavior to inspect.
Two requirements for trustworthy GPU fuzzing
FuzzGPU's significance begins with treating these as coupled requirements rather than separate improvements. The first is an execution-aware generator. It must build programs with real SIMT control flow, include both sides of a divergent path when they can reconverge, coordinate barriers across warps, and create memory interactions without losing track of which outcomes are uncertain. The goal is not to avoid complexity. It is to make complexity executable long enough to reach the design states where bugs can hide.
The second is an execution-aware oracle. FuzzGPU compares the device under test, or DUT, with a golden reference model, or GRM, but does not assume that the two should emit identical events at identical times. For ordinary operations, the harness reconstructs a meaningful instruction order. For memory operations whose results may vary legally, it sends the ambiguity to a separate consistency check rather than allowing one uncertain load to contaminate every later comparison. A difference is valuable only after the checker has asked whether it is forbidden, not merely unexpected.
This is why the title is more than a warning against imprecise language. “GPU fuzzing” names a relationship among a target, a model of its execution, a source of stress, and a way to decide what the stress revealed. Change the target's execution rules and the generator's assumptions can become invalid. Change the memory or completion behavior and the oracle can become a source of false positives. FuzzGPU makes the model itself part of the testing instrument.
That perspective also keeps the paper's security claim grounded. Finding a mismatch is not the same as demonstrating an attack. A private-memory address-calculation defect may matter under a threat model in which an attacker can launch a custom kernel. An instruction-cache deadlock may affect availability in the conditions where the sequence can be executed. An ISS-only defect may mislead verification without being a hardware vulnerability at all. The value of the method is that it can help separate these cases before they reach downstream systems, not that every generated program is an exploit.
A generated test, then, is only the beginning of evidence. It must run deeply enough to exercise the hardware, and its result must be judged against the GPU's actual rules rather than against a convenient sequential story. The next question is concrete: what happens inside Vortex and OpenGPGPU when threads diverge, synchronize, and write back at different times? Until that execution model is clear, “fuzz the GPU” remains a slogan rather than a reliable verification method.