Reese Levine
Current Organizations / Institutes
The organizations/institutes from the scholar's latest article
Research Subjects
Reese Levine has a total of 12 co-authors. Here are the top co-authors by number of shared publications:
- Tyler Sorensen
Microsoft Research, Redmond, USA
2 shared publications - Vijay Nagarajan
University of Utah, Salt Lake City, USA
2 shared publications - Andrés Goens
TU Darmstadt, Darmstadt, Germany
1 shared publication - Ashley Lee
University of California at Santa Cruz, Santa Cruz, USA
1 shared publication - Dennis Sprokholt
TU Munich, Munich, Germany
1 shared publication - Kyle Little
University of California at Santa Cruz, Santa Cruz, USA
1 shared publication
Latest Publications
- Open Access
- 10 April 2027
- Published by Association for Computing Machinery (ACM)
- p. 103-119
Beyond the Fence: Sound Compilation for GPU and Heterogeneous CPU+GPU Systems
- 10 April 2027
- Published by Association for Computing Machinery (ACM)
- p. 103-119
Open AccessBeyond the Fence: Sound Compilation for GPU and Heterogeneous CPU+GPU Systems
- Open Access
- 11 June 2026
- Published by Association for Computing Machinery (ACM)
- p. 66-79
Consistency and Coherence of the NVIDIA Grace-Hopper Superchip
- 11 June 2026
- Published by Association for Computing Machinery (ACM)
- p. 66-79
Open AccessConsistency and Coherence of the NVIDIA Grace-Hopper Superchip
- Open Access
- 9 October 2025
- Published by Association for Computing Machinery (ACM) in Proceedings of the ACM on Programming Languages
- Vol. 9 (OOPSLA2) , 697-725
SafeRace: Assessing and Addressing WebGPU Memory Safety in the Presence of Data Races
In untrusted execution environments such as web browsers, code from remote sources is regularly executed. To harden these environments against attacks, constituent programming languages and their implementations must uphold certain safety properties, such as memory safety. These properties must be maintained across the entire compilation stack, which may include intermediate languages that do not provide the same safety guarantees. Any case where properties are not preserved could lead to a serious security vulnerability. In this work, we identify a specification vulnerability in the WebGPU Shading Language (WGSL) where code with data races can be compiled to intermediate representations in which an optimizing compiler could legitimately remove memory safety guardrails. To address this, we present SafeRace, a collection of threat assessments and specification proposals across the WGSL execution stack. While our threat assessment showed that this vulnerability does not appear to be exploitable on current systems, it creates a ”ticking time bomb”, especially as compilers in this area are rapidly evolving. Given this, we introduce the SafeRace Memory Safety Guarantee (SMSG), two components that preserve memory safety in the WGSL execution stack even in the presence of data races. The first component specifies that program slices contributing to memory indexing must be race free and is implemented via a compiler pass for WGSL programs. The second component is a requirement on intermediate representations that limits the effects of data races so that they cannot impact race-free program slices. While the first component is not guaranteed to apply to all possible WGSL programs due to limitations on how some data types can be accessed, we show that existing language constructs are sufficient to implement this component with minimal performance overhead on many existing important WebGPU applications. We test the second component by performing a fuzzing campaign of 81 hours across 21 compilation stacks; our results show violations on only one (likely buggy) machine, thus providing evidence that lower-level GPU frameworks could relatively straightforwardly support this constraint. Finally, our assessments discovered GPU memory isolation vulnerabilities in Apple and AMD GPUs, as well as a security-critical miscompilation of WGSL in a pre-release version of Firefox.
- 9 October 2025
- Published by Association for Computing Machinery (ACM) in Proceedings of the ACM on Programming Languages
- Vol. 9 (OOPSLA2) , 697-725
Open AccessSafeRace: Assessing and Addressing WebGPU Memory Safety in the Presence of Data Races
In untrusted execution environments such as web browsers, code from remote sources is regularly executed. To harden these environments against attacks, constituent programming languages and their implementations must uphold certain safety properties, such as memory safety. These properties must be maintained across the entire compilation stack, which may include intermediate languages that do not provide the same safety guarantees. Any case where properties are not preserved could lead to a serious security vulnerability. In this work, we identify a specification vulnerability in the WebGPU Shading Language (WGSL) where code with data races can be compiled to intermediate representations in which an optimizing compiler could legitimately remove memory safety guardrails. To address this, we present SafeRace, a collection of threat assessments and specification proposals across the WGSL execution stack. While our threat assessment showed that this vulnerability does not appear to be exploitable on current systems, it creates a ”ticking time bomb”, especially as compilers in this area are rapidly evolving. Given this, we introduce the SafeRace Memory Safety Guarantee (SMSG), two components that preserve memory safety in the WGSL execution stack even in the presence of data races. The first component specifies that program slices contributing to memory indexing must be race free and is implemented via a compiler pass for WGSL programs. The second component is a requirement on intermediate representations that limits the effects of data races so that they cannot impact race-free program slices. While the first component is not guaranteed to apply to all possible WGSL programs due to limitations on how some data types can be accessed, we show that existing language constructs are sufficient to implement this component with minimal performance overhead on many existing important WebGPU applications. We test the second component by performing a fuzzing campaign of 81 hours across 21 compilation stacks; our results show violations on only one (likely buggy) machine, thus providing evidence that lower-level GPU frameworks could relatively straightforwardly support this constraint. Finally, our assessments discovered GPU memory isolation vulnerabilities in Apple and AMD GPUs, as well as a security-critical miscompilation of WGSL in a pre-release version of Firefox.