CVE-2026-64008 in Linux
Summary
by MITRE • 07/19/2026
In the Linux kernel, the following vulnerability has been resolved:
accel/rocket: fix UAF via dangling GEM handle in create_bo
rocket_ioctl_create_bo() inserts a GEM handle into the file's IDR via drm_gem_handle_create() early on, then performs several operations that can fail (sgt allocation, drm_mm insert, iommu_map). If any fail after the handle is live, the error path calls drm_gem_shmem_object_free() which kfree's the object without removing the handle from the IDR.
This leaves a dangling handle pointing to freed slab memory. Any subsequent ioctl using that handle (PREP_BO, FINI_BO, SUBMIT) calls drm_gem_object_lookup() and dereferences freed memory (UAF).
Fix by moving drm_gem_handle_create() to after all fallible operations succeed, matching the pattern used by panfrost, lima, and etnaviv.
Also fix drm_mm_insert_node_generic() whose return value was silently overwritten by iommu_map_sgtable() on the next line. Add the missing error check.
[tomeu: Move handle creation to the very end]
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 07/19/2026
This vulnerability represents a use-after-free condition in the Linux kernel's rocket driver that stems from improper handling of GEM (Graphics Execution Manager) object lifecycle management during buffer object creation. The issue occurs within the rocket_ioctl_create_bo() function where a GEM handle is prematurely inserted into the file's IDR (Integer Descriptor Reference) structure before all subsequent operations complete successfully. This pattern creates a window where if any of the later operations fail, the system attempts to clean up by calling drm_gem_shmem_object_free() which frees the underlying object memory but leaves the handle reference intact in the IDR structure, creating a dangling pointer scenario.
The technical flaw manifests through a classic uninitialized use-after-free vulnerability classified under CWE-416, where memory is freed and then accessed through a stale reference. When subsequent ioctls attempt to use the dangling handle for operations such as PREP_BO, FINI_BO, or SUBMIT, the drm_gem_object_lookup() function dereferences the freed memory, leading to potential system crashes, privilege escalation, or arbitrary code execution depending on attacker control over the memory layout. This vulnerability directly maps to attack techniques described in MITRE ATT&CK framework under T1068 for escalation of privileges and T1547 for kernel-level persistence mechanisms.
The operational impact of this vulnerability is significant as it affects graphics processing capabilities within the Linux kernel, potentially allowing malicious users to exploit the race condition for privilege escalation. The fix implements a defensive programming pattern that moves the drm_gem_handle_create() call to occur after all fallible operations have completed successfully, ensuring that handles are only inserted into the IDR structure when the associated objects are guaranteed to remain valid throughout their lifetime. This approach mirrors established patterns used in other graphics drivers within the kernel such as panfrost, lima, and etnaviv, demonstrating industry best practices for preventing similar vulnerabilities.
Additional improvements in the patch address a secondary issue where drm_mm_insert_node_generic() return value was being silently overwritten by iommu_map_sgtable() on the following line, creating a potential logic error that could mask allocation failures. The corrected implementation ensures proper error handling throughout the memory management sequence by adding explicit error checking after the iommu mapping operation. This comprehensive fix not only resolves the immediate use-after-free vulnerability but also strengthens the overall robustness of the buffer object creation process by preventing cascading errors from propagating through the system's memory management subsystem.
The root cause analysis reveals a fundamental flaw in resource management ordering where the handle creation phase was decoupled from the object validity phase, creating an inconsistency between the IDR reference structure and actual memory allocation state. This pattern violation demonstrates how seemingly minor ordering issues in kernel driver development can create severe security implications, particularly in graphics subsystems where multiple concurrent operations require strict memory synchronization. The solution reinforces proper resource management principles by ensuring that all resources are fully validated and allocated before any references to them are established, aligning with the principle of least privilege and resource safety enforcement commonly recommended in secure coding practices for kernel development environments.