CVE-2026-98518: drm/nouveau/dmem: pin VRAM for the whole registered range
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 nouveaudmemchunkalloc() registers from DMEMCHUNKSIZE to DMEMCHUNKSIZE NRCHUNKS, but left the VRAM buffer object backing that region at DMEMCHUNKSIZE.
nouveaudmempageaddr() 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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
ubuntu/linux-hwe-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42~24.04.1 - Upgrade
Upgrade
ubuntu/linux-riscv-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1~24.04.1 - Upgrade
Upgrade
ubuntu/linuxto a version that resolves this vulnerability.Fixed in 7.0.0-42.42 - Upgrade
Upgrade
ubuntu/linux-awsto a version that resolves this vulnerability.Fixed in 7.0.0-1016.17 - Upgrade
Upgrade
ubuntu/linux-gcpto a version that resolves this vulnerability.Fixed in 7.0.0-1016.18 - Upgrade
Upgrade
ubuntu/linux-ibmto a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oem-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oracleto a version that resolves this vulnerability.Fixed in 7.0.0-1015.16 - Upgrade
Upgrade
ubuntu/linux-riscvto a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
Systems using the Linux kernel's nouveau DRM driver with device-private GPU memory migration are affected. The flaw is tied to the enlarged registered device-memory range and its undersized VRAM backing buffer object.
What condition triggers the invalid VRAM addressing?
Accessing pages beyond the first DMEM chunk in the registered device-private region causes nouveau_dmem_page_addr() to calculate addresses outside the backing VRAM buffer object. The issue results from the registered range being larger than the buffer object created for it.
How can I determine whether a kernel includes the fix?
Check whether the kernel contains either referenced stable commit 06c69c64686a31783c8bec6495dc22822d38c4ce or 64ca4cdd1031206424e6455f0ae4fb0560d8f46a. The fix sizes the VRAM buffer object to cover the entire registered range.