FuzzGPU: GPU Hardware Fuzzing

Overview

FuzzGPU shows why GPU hardware fuzzing must model execution, not just instructions. Across Vortex and OpenGPGPU, the series follows SIMT-aware generation through divergent paths, coordinated barriers, tainted memory interactions, and an oracle that separates out-of-order writeback and legal memory variation from defects. Reported results—20 previously unknown bugs, including 17 RTL and three ISS bugs, with 10 CVE identifiers—support productive exploration in the studied designs and simulator settings, not universal coverage or commercial-GPU claims. The practical lesson is to pair deep valid-path testing with explicit invalid-path and security-impact analysis.

Learning outcomes

GPU fuzzing needs execution-aware generation and checking because valid instructions alone do not preserve masks, barriers, or legal memory variation.
FuzzGPU's structured generation increases executed depth by preserving divergence, coordinated barriers, and memory interactions in the studied targets.
Its oracle separates out-of-order writeback and legal memory outcomes from candidate RTL or ISS defects.
The reported 20 bugs demonstrate bounded discovery value on Vortex and OpenGPGPU, not complete verification or universal GPU coverage.

Keywords

FuzzGPUSIMTGPUfuzzingVortexOpenGPGPUdivergencesynchronizationmemoryoracle

Chapters

FuzzGPU: GPU Execution Model

Why SIMT changes trustworthy hardware testing

9 min · Why SIMT changes trustworthy hardware testing

9 min

FuzzGPU: Warp and Barrier Execution

How masks, scheduling, and memory shape test behavior

9 min · How masks, scheduling, and memory shape test behavior

9 min

FuzzGPU: Valid GPU Test Generation

How structure buys executed depth

9 min · How structure buys executed depth

9 min

FuzzGPU: Deep GPU Tests, Fair Oracles

Why execution and interpretation must work together

8 min · Why execution and interpretation must work together

8 min

FuzzGPU: GPU Differential Oracles

How queues, barriers, and memory graphs make traces fair

9 min · How queues, barriers, and memory graphs make traces fair

9 min

FuzzGPU: Results on Vortex and OpenGPGPU

What completion, throughput, coverage, and ablation measure

11 min · What completion, throughput, coverage, and ablation measure

11 min

FuzzGPU: Bug Diagnosis and Security Impact

How traces become classified, conditional findings

13 min · How traces become classified, conditional findings

13 min

FuzzGPU: Hardware-Centered GPU Fuzzing

What to model, measure, and leave uncertain

10 min · What to model, measure, and leave uncertain

10 min

Preview every chapter · Unlock full text, audio, and video from chapter 4

Plans

Ch.1-3 FreeCh.4-8 Premium

FAQ

Why does GPU fuzzing need a GPU-specific execution model?

GPU fuzzing needs a GPU-specific execution model because SIMT masks, reconvergence, barriers, scheduling, and memory visibility determine whether tests execute deeply and whether differences are legal.

How does FuzzGPU keep generated GPU programs executable?

FuzzGPU keeps programs executable by combining a per-warp generation stack, globally planned barriers, interleaved memory generation, and taint tracking. These mechanisms preserve reachable paths and coordinated progress for the studied Vortex and OpenGPGPU targets.

How does FuzzGPU distinguish legal GPU variation from a bug?

FuzzGPU distinguishes them by ordering ordinary writebacks per warp, respecting barrier state, and validating tainted memory events against target-specific axioms. A persistent mismatch after these checks becomes a defect candidate, not an automatic vulnerability.

Does a FuzzGPU mismatch prove a security vulnerability?

No. A mismatch does not by itself prove a security vulnerability; it must survive fair comparison, be localized to the affected layer, and be linked to a reachable asset under an explicit threat model.