CUDA've done better - Hacking Nvidia GPUs for container escape and privilege escalation

The talk starts from a Pwn2Own NVIDIA category target, the NVIDIA Container Toolkit, and the question of whether a malicious container can run code on the host. The researchers mapped the attack surface: the Go management code, the GPU kernel driver, and the RISC-V GSP firmware. They focused on the open-source Linux kernel module, because containers on one host share a kernel, and found a use-after-free there. The vulnerability itself is not detailed, and NVIDIA had already patched it.

The middle section covers how they made the bug reliable. A freed object can be reclaimed by an allocation whose contents are copied back to user space through the ioctl buffer, which leaks whatever gets written into it. To win the race, they used the read-write semaphore's writer-preference behavior and reordered lock acquisitions so the timing became deterministic. They then corrupted a linked-list node to get an arbitrary unlink, overwrote a memory-mapping structure's start and size fields, and mapped all of physical memory into user space.

A recorded demo shows the exploit run inside a container and return a root shell on the host. The speaker said an AI coding agent wrote much of the final physical-memory exploitation. The takeaway is that a single driver bug can break container isolation when containers share the host kernel, and that GPU driver code deserves the same scrutiny as core kernel code.