CVE-2026-68240 in Linux
Summary
by MITRE • 08/10/2026
In the Linux kernel, the following vulnerability has been resolved:
drm/gpusvm: publish dpagemap early to avoid device mapping leak on error
drm_gpusvm_get_pages() only stored the local dpagemap into svm_pages->dpagemap on the success path. If a later page failed (e.g. -EOPNOTSUPP when ctx->allow_mixed is false) and jumped to err_unmap, svm_pages->dpagemap was still NULL, so __drm_gpusvm_unmap_pages() skipped device_unmap() and leaked the device mappings already created.
Assign svm_pages->dpagemap when the first device page is mapped so the err_unmap path can device_unmap() those mappings.
This issue was found by Sashiko AI review.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 08/10/2026
The vulnerability resides in the Linux kernel's direct rendering manager gpu subsystem specifically within the gpusvm module where improper handling of device page mapping leads to resource leakage. This flaw affects the drm_gpusvm_get_pages function which manages virtual memory pages for gpu operations and represents a classic case of incomplete error path handling that can result in system resource exhaustion over time.
The technical implementation flaw occurs when the drm_gpusvm_get_pages function only initializes the dpagemap structure on successful execution paths but fails to establish this mapping during error conditions. When subsequent pages encounter failures such as -EOPNOTSUPP due to context restrictions where ctx->allow_mixed is false, the code branches to err_unmap label. However, since svm_pages->dpagemap remains NULL at this point, the __drm_gpusvm_unmap_pages function skips the device_unmap() operation that would normally clean up previously established device mappings, resulting in a memory leak of gpu virtual address space mappings.
This vulnerability directly corresponds to CWE-404 which describes improper resource management where resources are not properly released during error conditions. The issue demonstrates poor defensive programming practices where error handling paths do not mirror the successful execution paths in terms of resource cleanup operations. The flaw creates a persistent resource leak that can accumulate over time as gpu memory allocations fail and error paths are executed repeatedly.
The operational impact of this vulnerability extends beyond simple memory consumption to potentially affect system stability and performance under sustained gpu workload conditions. When device mappings accumulate without proper cleanup, the gpu virtual memory subsystem can become fragmented and eventually exhaust available resources, leading to application failures or system instability. The leak becomes particularly problematic in systems with high gpu utilization where multiple processes are continuously allocating and deallocating gpu memory.
The mitigation strategy involves modifying the drm_gpusvm_get_pages function to initialize svm_pages->dpagemap immediately upon successful mapping of the first device page rather than waiting for all pages to be processed successfully. This ensures that when error paths are executed, the dpagemap structure contains valid information allowing __drm_gpusvm_unmap_pages to properly execute device_unmap operations and clean up all allocated gpu mappings. The fix aligns with ATT&CK technique T1486 which involves data destruction and resource exhaustion through improper resource management.
This vulnerability demonstrates the critical importance of maintaining consistent resource state across all code paths, particularly in kernel subsystems where resource leaks can have cascading effects on system stability. The issue highlights the necessity of comprehensive testing including error path validation to ensure that cleanup operations are properly executed regardless of execution flow. The fix represents a defensive programming pattern that establishes resource state early and ensures proper cleanup occurs even when subsequent operations fail, preventing the accumulation of leaked gpu virtual memory mappings that could eventually compromise system performance and reliability.
The vulnerability was identified through automated static analysis using Sashiko AI review tools, demonstrating how modern security analysis techniques can uncover subtle resource management flaws in complex kernel subsystems. This discovery process underscores the value of continuous security auditing and automated vulnerability detection in preventing resource leakage issues that might otherwise remain undetected until they manifest as system performance degradation or instability problems.