GPU local/shared memory not cleared between kernels (AMD, Apple, Qualcomm, Imagination): A GPU kernel reads whatever

Impact

A GPU kernel reads whatever the previous kernel left in local (shared/scratchpad) memory, including a kernel belonging to a different user, process or container. Trail of Bits recovered another process's LLM inference output token by token - on an AMD Radeon RX 7900 XT the leak was around 5.5 MB per GPU invocation, roughly 181 MB per query against a 7B model on llama.cpp. That is enough to reconstruct prompts, activations and responses, not just fragments. Affected vendors are AMD, Apple, Qualcomm and Imagination; NVIDIA, Intel and Arm tested clean and told CERT/CC they were not impacted. If you run AMD Instinct or ROCm, this is your bug and AMD was still investigating mitigations at disclosure.

Who can reach it

A co-tenant. The attacker needs only to run an ordinary OpenCL/Vulkan/Metal compute kernel on the same physical GPU - no privileges, no kernel exploit, no driver bug in the usual sense. Time-sliced sharing, MPS-style sharing and sequential job scheduling on the same device all qualify.

What to do

Qualcomm shipped firmware v2.07 (January 2024) and Imagination fixed it in DDK 23.3 (December 2023); Apple fixed it in silicon from A17/M3 onward, leaving older Apple GPUs UNPATCHABLE; ChromeOS shipped AMD and Qualcomm mitigations in stable 120 / LTS 114. AMD's position at disclosure was that devices remained vulnerable pending mitigation work - track AMD-SB-6010 for your specific Instinct parts rather than assuming a fix exists. Cost where a driver fix does exist: driver upgrade plus node drain to reload the kernel module. Where it does not, the only controls are refusing to share a GPU across trust boundaries, or having your runtime explicitly zero local memory at kernel entry - which costs measurable throughput on small kernels and has to be done by whoever compiles the kernels, not by you.

References