Trapped Handler

A Practical Performance Degradation Attack on NVIDIA vGPU via Preemption Manipulation

📄 Read the Paper ❝ Cite

ACM CCS 2026 · The Hague, Netherlands · Nov 15–19, 2026

#What is Trapped Handler?

NVIDIA vGPU lets multiple virtual machines share one physical GPU, and cloud providers rely on its scheduler to keep tenants isolated and bill them fairly by GPU time. Trapped Handler breaks that guarantee.

We reverse-engineered the GPU preemption mechanism — the routine the scheduler runs at the end of every time slice to switch execution from one VM to another. At the heart of it is a trap handler that lives in GPU memory. We discovered that on NVIDIA GPUs, this handler sits on a writable page in the context's own address space, so an unprivileged GPU program can simply overwrite it.

By inserting a spinning loop into its own trap handler, an attacker VM refuses to yield the GPU when preempted. The GPU's timeout-based fallback lets the trapped context hog the GPU for roughly 4 secondsbefore it is terminated — an eternity next to the ~2 ms time slice. Repeat it, and the attacker starves every co-located victim of GPU time. The result is a cross-VM performance-degradation (denial-of-service) attack that works even under NVIDIA's strongest QoS scheduling policies.

#How the attack works

The vulnerability chains together three facts we uncovered about NVIDIA GPUs:

1. Preemption runs a trap handler

   When a context is preempted, the GPU invokes a ~111-instruction trap handler ending in the undocumented EXIT.PREEMPTED.NO_ATEXIT instruction. It preserves state, computes save locations, dispatches subroutines, and completes the context switch. (Takeaway 1)

2. The handler is writable by unprivileged code

   Each context has its own trap handler mapped into its virtual address space — on a page that, like all GPU pages in practice, is writable. A normal GPU program can modify it with ordinary memory writes and no error is raised. (Takeaway 2)

3. Preemption has a ~4-second timeout

   If the handler never completes (e.g. we branch it into an infinite loop), the GPU does not switch away instantly. It waits ~4000 ms before terminating the stuck context with an unspecified launch error — during which co-located VMs get no GPU time. (Takeaway 3)

#How bad is it?

We measured slowdown of a victim VM running real Blender, CNN-inference, and LLM-inference workloads while a single co-located attacker VM ran Trapped Handler.

On A10 GPUs the Best Effort slowdown reaches 429.3×. Even the policies specifically designed to guarantee per-VM isolation are violated by an order of magnitude or more.

It works on real clouds

We rented vGPU instances and ran the attack end-to-end (occupying the whole physical GPU so no third party was affected):

#Frequently asked questions

Why should I care about vGPU scheduling?

Cloud providers pack multiple tenants' VMs onto one physical GPU and bill by usage time. The vGPU scheduler is what keeps those tenants from interfering with one another and enforces the Quality-of-Service (QoS) each customer pays for. If one tenant can seize the GPU at will, co-located customers get degraded performance, missed service-level agreements, and inflated bills — a direct financial and availability impact.

What exactly is a "trap handler"?

It's a routine in GPU memory that the hardware invokes on certain system-level events. We found that preemption — swapping the running context out at the end of a time slice — invokes a specific handler that ends in the EXIT.PREEMPTED.NO_ATEXIT instruction. Because we could stall that handler and directly observe the effect on a co-located program, we confirmed it runs on every preemption.

Is this a bug in the GPU driver or the hardware?

It stems from the design of the preemption mechanism itself. Two design decisions combine to make it exploitable: (1) each context's trap handler lives on a page that is writable by unprivileged GPU code, and (2) preemption falls back to a coarse ~4-second timeout rather than forcibly reclaiming the GPU. Neither is documented, and both are baked into how NVIDIA GPUs handle preemption today.

Does an attacker need special privileges?

No. The attacker only needs to run ordinary GPU code inside their own VM — exactly what a paying cloud tenant is entitled to do. Modifying the trap handler uses regular memory writes; no kernel access, no hypervisor escape, no privileged instructions.

Can the attacker read the victim's data?

No — this is a performance-degradation / denial-of-service attack, not a data-leakage or memory-corruption attack. The attacker cannot see the victim's GPU memory; it can only starve the victim of GPU time and thereby slow it down dramatically or violate its QoS guarantees.

Which GPUs and clouds are affected?

We confirmed the attack on NVIDIA T4, A10, and L4 vGPUs, and on A40 in the wild. It succeeds on Alibaba Cloud, Microsoft Azure, and Vultr, and remains effective across vGPU software versions 18.5–18.6 and 19.0–19.4. Because every vGPU deployment relies on the same proprietary scheduler, the underlying weakness is not specific to one provider.

Do the "strong isolation" scheduling policies protect me?

Not fully. Equal Share and Fixed Share are marketed as providing strong per-VM performance isolation, and they do resist the naive version of the attack because the scheduler compensates VMs that overuse the GPU. But the scheduler does not compensate GPU time lost when a context is terminated by the preemption timeout. Our adapted attack deliberately triggers that timeout on every run, bypassing compensation and still degrading victims by 6.2×–41.1×.

How can this be fixed?

The most fundamental fix is to make the trap-handler page read-only. NVIDIA page tables already have a read-only bit per page (unused in practice); the vGPU manager should set it for the trap handler so unprivileged code cannot modify it. Cloud providers using Equal Share or Fixed Share can also detect the attack, since the attacker VM consumes visibly more GPU time (via nvidia-smi vgpu -sl) — though this signal is unavailable under the default Best Effort policy.

Has this been disclosed to vendors?

Yes. We disclosed our findings to NVIDIA, Alibaba, Azure, and Microsoft in April 2026. For all cloud evaluations we occupied the entire physical GPU ourselves, so no third-party tenants were affected by our experiments.

#Authors

• Cheng GuUniversity of Rochester
• Fatemeh MoradihaghighiClemson University
• Daniel GenkinGeorgia Tech
• Zhuo LiHydrox AI
• Mengyuan LiUSC
• Zhenkai ZhangClemson University
• Yanan GuoUniversity of Rochester

#Cite this work

@inproceedings{trappedhandler2026,
  title     = {Trapped Handler: A Practical Performance Degradation
               Attack on NVIDIA vGPU via Preemption Manipulation},
  author    = {Gu, Cheng and Moradihaghighi, Fatemeh and Genkin, Daniel
               and Li, Zhuo and Li, Mengyuan and Zhang, Zhenkai
               and Guo, Yanan},
  booktitle = {Proceedings of the 2026 ACM SIGSAC Conference on Computer
               and Communications Security (CCS '26)},
  year      = {2026},
  address   = {The Hague, Netherlands},
  publisher = {ACM},
  doi       = {10.1145/3830454.3846621},
  isbn      = {979-8-4007-2871-6/2026/11},
}