What GPU Drivers Actually Do: Why They Are Large, Privileged, and Hard to Audit
For executives
Every GPU security vulnerability in the kernel-mode driver category exists because the GPU driver is an extraordinarily complex piece of software running with kernel-level privileges, processing inputs from untrusted user-space applications. Understanding what the driver actually does explains why it is such a persistent vulnerability surface: it is doing an inherently difficult job, in a proprietary codebase, under continuous research scrutiny.
The GPU driver's responsibilities
The NVIDIA GPU driver (nvidia.ko on Linux, nvlddmkm.sys on Windows) handles everything that connects user-space CUDA applications to physical GPU hardware:
Memory management: allocating VRAM regions for GPU workloads, managing page tables on the GPU, handling Unified Virtual Memory migration between CPU and GPU, and tracking which memory regions belong to which CUDA contexts.
Scheduling: deciding which GPU contexts run on which streaming multiprocessors, at what priority, and for how long.
Command dispatch: translating high-level CUDA API calls into low-level hardware commands.
Device initialisation: configuring the GPU hardware at startup, loading firmware, initialising interconnects (PCIe, NVLink), and setting up interrupt handling.
Power management: controlling GPU clock frequencies, voltage scaling, thermal management, and power states.
Security enforcement: managing CUDA context isolation, MIG partition boundaries, and access control for GPU resources.
Why the driver runs in kernel space
GPU drivers run as kernel modules because they need direct access to hardware resources that user-space code cannot reach: physical memory addresses, interrupt handling, DMA setup, and I/O memory mapping. This is a necessary consequence of how GPU hardware interfaces with the system, not inefficiency.
The scale and complexity problem
The NVIDIA GPU driver is one of the largest kernel modules in regular use. A single driver release for the Linux kernel weighs in at tens of thousands of source files. The driver supports every NVIDIA GPU from the past decade across thousands of hardware configurations. It has accumulated decades of features, optimisations, and compatibility code.
Large, complex codebases have more bugs. More bugs means more security vulnerabilities.
The proprietary code problem
The NVIDIA GPU driver is proprietary. Security researchers who want to find vulnerabilities must use binary analysis, reverse engineering, and black-box fuzzing. NVIDIA's November 2022 announcement that it would open-source its GPU kernel modules for Linux was a partial step: the open-sourced components are the firmware interface modules, not the driver's core memory management and scheduling logic.
The ioctl attack surface
User-space CUDA programs communicate with the kernel driver via ioctl calls to device files. The driver dispatches calls to the appropriate handler based on the command code. The set of ioctl commands supported by the NVIDIA driver is large and complex. The driver's ioctl handlers receive data structures from user space and must validate those structures completely before acting on them. Any validation failure is a potential privilege escalation path.
Edera's security research, published in 2026, described the NVIDIA driver's ioctl surface as "hundreds of undocumented commands, C code processing untrusted input in ring 0."