CVE-2024-36018 in Linux
Summary
by MITRE • 05/30/2024
In the Linux kernel, the following vulnerability has been resolved:
nouveau/uvmm: fix addr/range calcs for remap operations
dEQP-VK.sparse_resources.image_rebind.2d_array.r64i.128_128_8 was causing a remap operation like the below.
op_remap: prev: 0000003fffed0000 00000000000f0000 00000000a5abd18a 0000000000000000 op_remap: next: op_remap: unmap: 0000003fffed0000 0000000000100000 0 op_map: map: 0000003ffffc0000 0000000000010000 000000005b1ba33c 00000000000e0000
This was resulting in an unmap operation from 0x3fffed0000+0xf0000, 0x100000 which was corrupting the pagetables and oopsing the kernel.
Fixes the prev + unmap range calcs to use start/end and map back to addr/range.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 05/07/2026
The vulnerability identified as CVE-2024-36018 resides within the Linux kernel's nouveau graphics driver component, specifically affecting the uvmm (Unified Virtual Memory Manager) subsystem. This issue manifests during remap operations involving sparse resource management in graphics processing units. The flaw occurs when the nouveau driver processes certain GPU memory operations, particularly those involving image rebinding operations as demonstrated by the dEQP-VK.sparse_resources.image_rebind.2d_array.r64i.128_128_8 test case. The vulnerability represents a critical memory management error that can lead to kernel crashes and system instability.
The technical root cause of this vulnerability stems from incorrect address and range calculations within the remap operation handling code. Specifically, the driver fails to properly compute the start and end addresses when processing memory unmapping operations during GPU memory management. The debug output shows that the previous memory mapping operation had a range starting at 0x3ffed0000 with a size of 0xf0000 bytes, but the subsequent unmap operation incorrectly calculates the range as 0x100000 bytes starting from the same base address. This miscalculation results in an improper memory range that extends beyond the intended boundaries, causing memory corruption in the page table structures. The vulnerability follows CWE-129 weakness pattern related to improper validation of array indices and memory access boundaries.
The operational impact of this vulnerability is severe as it can cause immediate system crashes through kernel oops conditions, leading to complete system instability and potential denial of service. When the nouveau driver encounters memory operations that trigger this specific calculation error, the corrupted page tables can cause the kernel to panic and terminate. This affects systems running Linux with NVIDIA graphics hardware, particularly those utilizing Vulkan graphics applications that perform sparse resource operations. The vulnerability is especially concerning in server and workstation environments where continuous system availability is critical, as it can cause unexpected system reboots and data loss during graphics-intensive operations.
Mitigation strategies for this vulnerability should focus on applying the kernel patch that corrects the address and range calculation logic in the nouveau driver's uvmm subsystem. The fix implements proper start/end address calculations and ensures that remap operations correctly map back from address/range parameters to prevent overlapping or incorrect memory operations. System administrators should prioritize updating to kernel versions containing the patched code, typically those released after the vulnerability disclosure. Additionally, monitoring for kernel oops messages related to nouveau driver memory management can help identify systems that may be vulnerable. Organizations should also consider implementing runtime protections such as kernel address space layout randomization and memory protection mechanisms, though these provide secondary defense rather than direct fixes for the specific calculation error. The vulnerability demonstrates the importance of proper memory management in graphics drivers and highlights the need for comprehensive testing of sparse resource operations in graphics APIs like Vulkan.