7.8

CVE-2026-64008

accel/rocket: fix UAF via dangling GEM handle in create_bo

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]
Daten sind bereitgestellt durch National Vulnerability Database (NVD)
Linux ≫ Linux Kernel Version >= 6.18 < 6.18.35
Linux ≫ Linux Kernel Version >= 6.19 < 7.0.12
Linux ≫ Linux Kernel Version 7.1 Update rc1
Linux ≫ Linux Kernel Version 7.1 Update rc2
Linux ≫ Linux Kernel Version 7.1 Update rc3
Linux ≫ Linux Kernel Version 7.1 Update rc4
Linux ≫ Linux Kernel Version 7.1 Update rc5
VulnDex Vulnerability Enrichment
Diese Information steht angemeldeten Benutzern zur Verfügung. Login Login
Zu dieser CVE wurde keine Warnung gefunden.
EPSS Metriken
Typ Quelle Score Percentile
EPSS FIRST.org 0.13% 0.027
CVSS Metriken
Quelle Base Score Exploit Score Impact Score Vector String
416baaa9-dc9f-4396-8d5f-8c081fb06d67 7.8 1.8 5.9
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CWE-416 Use After Free

The product reuses or references memory after it has been freed. At some point afterward, the memory may be allocated again and saved in another pointer, while the original pointer references a location somewhere within the new allocation. Any operations using the original pointer are no longer valid because the memory "belongs" to the code that operates on the new pointer.

https://git.kernel.org/stable/c/18abd88d19ea195e2e1547fca0970c2f91d77a42
Patch
https://git.kernel.org/stable/c/451f1ccbbdb7b65021646704b15902655f8d228a
Patch
https://git.kernel.org/stable/c/f706e6a4ce75585af979aec3dcbdce68bc76306b
Patch