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

CVE-2026-64099 Overview

CVE-2026-64099 is a use-after-free vulnerability in the Linux kernel's Broadcom VideoCore V3D Direct Rendering Manager (drm/v3d) driver. The flaw resides in the CPU job ioctl error path, where kvfree() is invoked on the cpu_job timestamp and performance query arrays after v3d_job_cleanup() has already dropped the job's last reference and freed the underlying cpu_job structure. The same error path also produces a NULL pointer dereference on early v3d_job_init() failures and leaks one drm_syncobj reference per query. Local unprivileged users with access to the V3D device node can trigger the condition through crafted ioctl calls.

Critical Impact
Local attackers with access to the drm/v3d device can trigger memory corruption in kernel space, potentially escalating privileges or destabilizing the system.

Affected Products

Linux kernel builds shipping the drm/v3d driver (Broadcom VideoCore V3D)
Systems using Raspberry Pi and other Broadcom SoC platforms with V3D GPU support
Downstream distributions consuming affected upstream kernel releases prior to the fix

Discovery Timeline

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

Technical Details for CVE-2026-64099

Vulnerability Analysis

The defect exists in the CPU job ioctl teardown logic within the drm/v3d driver. When the ioctl handler fails after job initialization, control transfers to a fail: label that calls v3d_job_cleanup() on the cpu_job. That cleanup releases the job's last kref and frees the cpu_job allocation. The fail label then continues to call kvfree() on cpu_job->timestamp_query.queries and cpu_job->performance_query.queries, dereferencing memory that has already been returned to the allocator.

On an earlier failure path within v3d_job_init(), v3d_job_deallocate() zeroes the local pointer, so the same code produces a NULL pointer dereference instead of a stale-pointer read. Beyond the memory safety error, the manual kvfree() calls only release the array storage; they do not invoke drm_syncobj_put() on the per-query syncobjs that v3d_timestamp_query_info_free() and v3d_performance_query_info_free() normally release. Each failed submission therefore leaks one syncobj reference per query.

Root Cause

The root cause is a divergence between the success and error teardown paths. On success, the scheduler's .free_job callback releases the query arrays and their syncobjs. On failure, the ioctl handler duplicated only part of that logic and executed it after the job was already freed. The upstream fix unifies teardown into the cpu_job kref destructor, mirroring v3d_render_job_free(), so a single path handles both scheduler and ioctl error cleanup.

Attack Vector

Exploitation requires local access and the ability to open the V3D DRM device node, typically /dev/dri/card* or /dev/dri/renderD*. An attacker submits a CPU job through the V3D ioctl interface with parameters engineered to trigger the failure branch after cpu_job allocation. The resulting use-after-free can be groomed to overlap with attacker-controlled kernel objects, enabling privilege escalation. The syncobj reference leak provides an additional primitive for exhausting kernel resources.

No public proof-of-concept exploit is available at this time, and the issue is not listed in the CISA Known Exploited Vulnerabilities catalog. Technical details are available in the upstream kernel commit.

Detection Methods for CVE-2026-64099

Indicators of Compromise

Kernel oops or BUG: KASAN: use-after-free entries in dmesg referencing v3d_job_cleanup, v3d_submit_cpu_ioctl, or kvfree
Unexpected NULL pointer dereferences originating from the drm/v3d module during CPU job submission
Repeated ioctl failures from unprivileged processes against /dev/dri/renderD* on V3D-enabled hardware

Detection Strategies

Enable Kernel Address Sanitizer (KASAN) on test kernels to surface the use-after-free during fuzzing of the V3D ioctl surface
Audit process access to DRM render nodes and correlate crashes with syscall traces containing DRM_IOCTL_V3D_SUBMIT_CPU
Monitor for abnormal growth in DRM syncobj reference counts, which may indicate exploitation attempts leveraging the reference leak

Monitoring Recommendations

Forward kernel logs to a centralized analytics platform and alert on stack traces referencing v3d_ symbols alongside memory-safety keywords
Track unexpected reboots or GPU driver resets on Broadcom V3D platforms, particularly Raspberry Pi fleets
Baseline expected users of DRM render nodes and flag ioctl activity from processes outside that baseline

How to Mitigate CVE-2026-64099

Immediate Actions Required

Apply the upstream stable kernel updates that include commits 0f8efc45740b, 69c2a1fec2e7, acd55ea40d03, and b0fe80c0b925 as soon as vendor packages are available
Restrict access to /dev/dri/renderD* and /dev/dri/card* device nodes to trusted local users and services
Inventory affected assets running Broadcom V3D hardware, prioritizing multi-tenant and shared-user systems

Patch Information

The fix unifies CPU job teardown into the cpu_job kref destructor, mirroring v3d_render_job_free(). The scheduler's .free_job slot reverts to the generic v3d_sched_job_free(), and the ioctl fail label drops the manual kvfree() calls. This yields a single teardown path reached from both the scheduler and the ioctl error path, eliminating the use-after-free, the NULL dereference, and the syncobj leak. Patch commits are available at git.kernel.org 0f8efc45740b, 69c2a1fec2e7, acd55ea40d03, and b0fe80c0b925.

Workarounds

Where patching is not immediately feasible, remove or blacklist the v3d kernel module on systems that do not require GPU acceleration
Tighten permissions on DRM device nodes using udev rules to limit access to a dedicated video or render group
Deploy Linux security modules such as SELinux or AppArmor to constrain untrusted processes from opening DRM render nodes

bash

# Example udev rule to restrict access to V3D render nodes
# /etc/udev/rules.d/99-v3d-restrict.rules
KERNEL=="renderD*", SUBSYSTEM=="drm", GROUP="render", MODE="0660"
KERNEL=="card*", SUBSYSTEM=="drm", GROUP="video", MODE="0660"

# Optionally blacklist the v3d module if GPU acceleration is not required
echo "blacklist v3d" | sudo tee /etc/modprobe.d/blacklist-v3d.conf
sudo update-initramfs -u