CVE-2026-64008: Linux kernel · accel/rocket: fix UAF via dangling GEM handle in create_bo
Source GCVE Database
Not known to be exploited · CVSS 7.8 High.
Data as of 26 Oct 2026, 14:05 UTC
- EPSS
- 0.1% chance of exploitation in 30 days – higher than 6% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HExploitation evidence
Disclosed: evidence found.
CVE published 19 Jul 2026
Detectable: no evidence on record.
No public nuclei template indexed
Weaponised: no evidence on record.
No public exploit code indexed in Metasploit or Exploit-DB
Exploited in the wildExploited: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq MirageSeen by Mirage: no evidence on record.
No attack traffic recorded by OffSeq Mirage sensors
A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 26 Oct 2026.
What to do
AI-suggested
A fix has been implemented in the Linux kernel that moves the GEM handle creation until after all fallible operations succeed and adds missing error checks. Users should update to the fixed Linux kernel version containing this patch. Since this is not a cloud service, remediation depends on applying the official kernel update. Patch status is not explicitly stated in the provided data; check the vendor or Linux kernel advisory for the exact fixed version and update accordingly.
Description
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]
References
- nvd.nist.gov/vuln/detail/CVE-2026-64008 (opens in a new tab)
- git.kernel.org/stable/c/18abd88d19ea195e2e1547fca0970c2f91d77a42 (opens in a new tab)
- git.kernel.org/stable/c/451f1ccbbdb7b65021646704b15902655f8d228a (opens in a new tab)
- git.kernel.org/stable/c/f706e6a4ce75585af979aec3dcbdce68bc76306b (opens in a new tab)