CVE-2026-64008: Linux Kernel Use-After-Free Vulnerability

CVE-2026-64008 Overview

CVE-2026-64008 is a use-after-free (UAF) vulnerability in the Linux kernel's accel/rocket accelerator driver. The flaw resides in rocket_ioctl_create_bo(), which registers a Graphics Execution Manager (GEM) handle in the file's IDR before completing all fallible allocations. If any subsequent step fails, the error path frees the object without removing the live handle, leaving a dangling reference to freed slab memory.

Critical Impact
A local, low-privileged user can trigger the failure path and reuse the dangling handle through follow-on ioctls (PREP_BO, FINI_BO, SUBMIT) to dereference freed kernel memory, enabling privilege escalation or arbitrary kernel code execution.

Affected Products

Linux kernel builds containing the accel/rocket driver prior to the fix commits
Distributions shipping the vulnerable drivers/accel/rocket code path with the accelerator IOCTL interface exposed to unprivileged users
Systems that expose the Rockchip NPU accelerator device node to local userspace

Discovery Timeline

2026-07-19 - CVE-2026-64008 published to the National Vulnerability Database (NVD)
2026-07-20 - Last updated in NVD database

Technical Details for CVE-2026-64008

Vulnerability Analysis

The vulnerability is a classic use-after-free triggered by an ordering error in kernel object lifecycle management. rocket_ioctl_create_bo() calls drm_gem_handle_create() early in its execution, which inserts the buffer object handle into the calling file's IDR (ID Radix tree). At that instant, the handle becomes globally visible to any other ioctl operating on the same file descriptor.

The function then performs several allocations and mappings that can fail: scatter-gather table (sgt) allocation, drm_mm range insertion, and iommu_map_sgtable(). When any of these fail, the error path invokes drm_gem_shmem_object_free(), which uses kfree() on the underlying object without invalidating or removing the handle from the IDR.

A secondary defect compounds the problem: the return value of drm_mm_insert_node_generic() is silently overwritten by the subsequent iommu_map_sgtable() call, so a drm_mm failure is not checked and can leave the driver in an inconsistent state before the UAF window opens.

Root Cause

The root cause is a lifecycle ordering violation. The GEM handle is exposed to userspace before construction completes, breaking the invariant that only fully-initialized objects should be reachable through the IDR. Combined with the missing error check on drm_mm_insert_node_generic(), the object can be freed while an attacker-controlled handle still references it.

Attack Vector

A local attacker with access to the accelerator device node opens the DRM/accel file and issues a CREATE_BO ioctl crafted to force one of the fallible steps to fail. Provoking iommu_map or drm_mm failures via resource pressure or oversized allocations frees the shmem object while leaving the handle live. The attacker then issues PREP_BO, FINI_BO, or SUBMIT with the same handle. drm_gem_object_lookup() returns the freed pointer, and the driver dereferences reclaimed slab memory. With heap grooming, this yields kernel memory corruption and privilege escalation from an unprivileged local context.

No public proof-of-concept code is available. Technical detail is documented in the upstream fix commits, including commit 18abd88d19ea, commit 451f1ccbbdb7, and commit f706e6a4ce75.

Detection Methods for CVE-2026-64008

Indicators of Compromise

Kernel oops or general protection fault messages referencing drm_gem_object_lookup, drm_gem_shmem_object_free, or rocket_ioctl_* symbols in dmesg
KASAN reports of use-after-free in rocket_ioctl_prep_bo or rocket_ioctl_submit when KASAN is enabled
Unexpected process crashes or kernel panics originating from /dev/accel/accel* device consumers

Detection Strategies

Enable Kernel Address Sanitizer (KASAN) and slab debugging on test kernels to surface the UAF at the point of dereference
Audit auditd for ioctl syscalls against accel device nodes from non-privileged UIDs and correlate with subsequent kernel warnings
Monitor for repeated CREATE_BO failures followed by PREP_BO, FINI_BO, or SUBMIT calls on the same file descriptor, which is atypical of legitimate accelerator workloads

Monitoring Recommendations

Ship kernel ring buffer and journald logs to a centralized store and alert on kernel oops, BUG:, and KASAN strings
Track process access patterns to /dev/accel/* and flag non-service accounts opening these devices
Enable panic_on_oops=1 on sensitive hosts so exploitation attempts halt rather than allow the attacker to iterate on heap grooming

How to Mitigate CVE-2026-64008

Immediate Actions Required

Apply the upstream Linux kernel patch that moves drm_gem_handle_create() to the end of rocket_ioctl_create_bo() after all fallible operations succeed
Rebuild or update to a distribution kernel that incorporates the fix commits referenced in git.kernel.org
Restrict access to /dev/accel/* device nodes to trusted service accounts using udev rules and group ownership until patched kernels are deployed

Patch Information

The fix reorders rocket_ioctl_create_bo() so the GEM handle is created only after sgt allocation, drm_mm insertion, and iommu_map all succeed. This matches the pattern already used by panfrost, lima, and etnaviv drivers. The patch also adds the missing return-value check for drm_mm_insert_node_generic(). See kernel commit 18abd88d19ea, kernel commit 451f1ccbbdb7, and kernel commit f706e6a4ce75.

Workarounds

Unload or blacklist the rocket kernel module on systems that do not require the Rockchip NPU accelerator
Tighten permissions on /dev/accel/accel* to root-only until the patched kernel is in place
Deploy Mandatory Access Control (SELinux or AppArmor) policies that deny ioctl access to accelerator device nodes for unconfined user domains

bash

# Restrict accelerator device access until patched kernel is deployed
sudo chmod 0600 /dev/accel/accel*
sudo chown root:root /dev/accel/accel*

# Optionally blacklist the driver
echo 'blacklist rocket' | sudo tee /etc/modprobe.d/blacklist-rocket.conf
sudo update-initramfs -u