CVE-2026-98518 in Linux
Summary
by MITRE • 10/18/2026
In the Linux kernel, the following vulnerability has been resolved:
drm/nouveau/dmem: pin VRAM for the whole registered range
Commit c32287471077 ("gpu/drm/nouveau: enable THP support for GPU memory migration") grew the device-private region that nouveau_dmem_chunk_alloc() registers from DMEM_CHUNK_SIZE to DMEM_CHUNK_SIZE * NR_CHUNKS, but left the VRAM buffer object backing that region at DMEM_CHUNK_SIZE.
nouveau_dmem_page_addr() returns chunk->bo->offset plus the page's offset within the registered region, so every page past the first chunk resolves to VRAM outside the buffer object.
Size the buffer object to the region it backs.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/19/2026
The Linux kernel driver for NVIDIA graphics hardware, specifically the nouveau DRM subsystem, contained a critical memory management flaw related to how virtual random access memory is allocated and mapped during GPU memory migration operations. This vulnerability stems from an inconsistency introduced when support for Transparent Huge Pages was enabled for GPU memory migration. The commit responsible for this feature expansion increased the size of the device-private region registered by the nouveau_dmem_chunk_alloc function, scaling it up significantly to accommodate larger contiguous memory blocks required for efficient page table management and performance optimization. However, while the logical address space registration was expanded, the underlying physical buffer object representing the actual VRAM allocation remained fixed at a smaller default chunk size rather than being scaled proportionally to match the newly registered region.
This architectural mismatch creates a severe out-of-bounds memory access scenario within the kernel's graphics subsystem. When the nouveau_dmem_page_addr function is invoked to resolve the physical address for pages located beyond the initial small buffer object boundary, it calculates addresses that point into VRAM regions not covered by the allocated buffer object. Consequently, any attempt to access or manipulate GPU memory in these extended ranges results in reading from or writing to unallocated or improperly mapped hardware memory locations. This constitutes a classic out-of-bounds read and write vulnerability, where the kernel operates outside its intended memory boundaries due to incorrect size calculations during resource allocation.
The operational impact of this flaw is substantial for system stability and security integrity. An attacker who can trigger GPU memory migration operations through maliciously crafted graphics commands or applications may exploit this discrepancy to cause a kernel panic by corrupting unrelated memory structures, leading to a denial of service condition. Furthermore, if the out-of-bounds write targets specific control structures or sensitive data areas within VRAM that are subsequently interpreted by the CPU or other GPU engines, it could potentially lead to arbitrary code execution with kernel privileges. The vulnerability effectively bypasses standard memory isolation mechanisms because the driver fails to enforce strict boundaries between allocated resources and their logical mappings, allowing for unauthorized access to hardware memory space.
From a classification perspective, this issue aligns closely with CWE-125 Out-of-bounds Read and CWE-787 Out-of-bounds Write, as it involves accessing memory locations beyond the intended buffer limits due to improper size validation during allocation. In terms of attack vectors, this vulnerability can be leveraged within the context of ATT&CK technique T1059 Command and Scripting Interpreter if an attacker uses scripting tools to trigger GPU workloads, or more directly under privilege escalation pathways where local users exploit kernel memory corruption to gain elevated access rights. The root cause is fundamentally a logic error in resource sizing that violates the principle of least privilege by granting broader memory access than necessary for the specific buffer object constraints.
Mitigation strategies primarily involve applying the upstream Linux kernel patch that corrects this allocation discrepancy. System administrators and developers must ensure that the nouveau driver version includes the fix which sizes the buffer object to exactly match the region it backs, thereby eliminating the gap between logical registration and physical allocation. Until such patches are applied, limiting GPU access privileges for untrusted users or disabling specific memory migration features may reduce exposure risk. Regular security audits of kernel graphics drivers should include verification that allocated buffer objects strictly correspond to their registered address ranges to prevent similar out-of-bounds exploitation vectors in other subsystems.