CVE-2026-72311 in Linux
Summary
by MITRE • 08/15/2026
In the Linux kernel, the following vulnerability has been resolved:
drm/xe: free madvise VMA array on L2 flush failure
xe_vm_madvise_ioctl() allocates madvise_range.vmas in get_vmas(). After get_vmas() succeeds with at least one VMA, error paths must go through free_vmas so the array is released before the madvise details are destroyed.
The L2 flush validation path added for PAT madvise rejects some SVM/userptr ranges after get_vmas() has succeeded, but jumps directly to madv_fini. This skips kfree(madvise_range.vmas), leaking the VMA array on each failed ioctl.
Jump to free_vmas instead, matching the other validation failure paths after get_vmas() has succeeded.
(cherry picked from commit c3a1c3579b1250060da73507a4acef712974c78a)
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 08/15/2026
This vulnerability exists within the Linux kernel's graphics subsystem, specifically in the x86e driver implementation where improper error handling leads to memory leaks during madvise operations. The issue manifests in the xe_vm_madvise_ioctl() function which manages memory management advice operations for GPU virtual memory areas. When processing madvise requests, the code allocates a VMA array through get_vmas() function but fails to properly clean up this allocation when subsequent validation steps encounter failures.
The technical flaw stems from inconsistent error handling patterns within the driver's validation logic. After successfully allocating the madvise_range.vmas array in get_vmas(), the code properly handles cleanup through free_vmas() in most failure paths. However, during L2 flush validation for PAT madvise operations, the code directly jumps to madv_fini when certain SVM or userptr ranges are rejected, bypassing the necessary free_vmas() call that would release the allocated VMA array. This creates a memory leak where each failed ioctl operation retains references to previously allocated virtual memory area structures.
The operational impact of this vulnerability extends beyond simple memory consumption issues as it represents a persistent resource leak that can accumulate over time during graphics operations. Such leaks can degrade system performance, potentially leading to memory exhaustion under sustained workload conditions. The vulnerability affects systems utilizing the x86e graphics driver and is particularly concerning in server environments or applications requiring extensive GPU memory management operations where repeated madvise ioctl calls occur.
This issue aligns with CWE-401: "Improper Release of Memory Before Removing Last Reference" and demonstrates poor adherence to defensive programming practices. The fix implements consistent error handling by redirecting the L2 flush validation failure path to use free_vmas() instead of directly jumping to madv_fini, ensuring proper resource cleanup regardless of where validation failures occur. From an ATT&CK perspective, this represents a resource exhaustion technique that could be leveraged in sustained denial-of-service scenarios against graphics-intensive applications or systems.
The fix maintains the existing security model while addressing the specific memory management inconsistency. By ensuring all error paths following successful get_vmas() allocation properly invoke free_vmas(), the implementation aligns with standard kernel programming practices for resource management and prevents accumulation of leaked virtual memory area structures. This change preserves the driver's functionality while eliminating the memory leak that could potentially impact system stability under prolonged usage conditions.